Re: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
On Fri, 22 Feb 2008 18:53:48 -0500 Barry Warsaw <[EMAIL PROTECTED]> wrote: now is > In 50 years, our grandchildren will be writing code with brain > implants and displays burned right into their retina, and they'll / > still/ be subject to 79 characters. I laugh every time I think that > they'll have no idea why it is, but they'll still be unable to change > it. :) There are reasons (other than antiquated media formats) for a coding standard to mandate a line length of 70-80 characters: to improve the readability of the source code. Depending on who (and how) you ask, the most comfortable line length for people to read will vary some, but 70 characters is close to the maximum you'll get, because it gets harder to track back across the page as lines get longer. While code is so ragged that that's probably not as much of a problem, comments aren't. Formatting those to a max of ~70 characters makes them easy to read. Formatting your program so that block comments and code are about the same makes optimal use of the display space. Whether the readability issue has anything to do with why 80 column cards dominated the industry (some were as short as 24 columns, and I could swear I saw a reference to 120-column cards *somewhere*) is left as an exercise for the reader. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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] [OT] Re: getpass and stdin
On Tue, 26 Feb 2008 15:32:03 -0500 "Leif Walsh" <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > > 1) I am willing to type in the password, which is obvious to anyone who > > can read a simple script. That just doesn't work for a program you want > > to run in the background to type it in every time. > > I recommend you just hack on this getmail program and give it a daemon > mode. That shouldn't be too large of a task, and it will certainly be > more secure (and you can even commit your changes as a new feature!). > Otherwise, your best bet is probably, as Charles said, making the > passfile work for you (maybe play with nfs and see if you can get it > to hide things...I'm no wizard with it, but I'm willing to bet it's > possible). Actually, the easiest thing is probably to use a "file" that's not really a file, like /dev/stdin or <(cat -), http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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 XML Validator
On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed <[EMAIL PROTECTED]> wrote: > lxml is good but not written in python and difficult to install and didn't > work > on MacOS X. lxml is built on top of libxml2/libxslt, which are bundled with most Unix-like OS's (including Mac OS X), or available in their package systems. Trying to install it from the repository is a PITA, because it uses both the easyinstall and Pyrex (later Cython) packages - which aren't bundled with anything. On the other hand, if it's in the package system (I no longer have macports installed anywhere, but believe it was there at one time), that solves all those problems. I believe they've excised the easyinstall source dependencies, though. Using lxml on OS X Tiger was problematical, because the versions of python, libxml2 and libxslt provided with Tiger were pretty much all older than lxml supported; I built python from macports, including current versions of libxml2, libxslt and lxml, and everything worked with no problems. (I later stopped working with this on the Mac because I need cx_Oracle as well, which doesn't exist for intel macs). On Leopard, Python is up to date, but libxml/libxslt seems a bit behind for lxml 2.0.x (no schematron support being the obvious problem). I went back to the 1.3.6 source tarball (which is what I'm using everywhere anyway), and "python setup.py install" worked like a charm. (So it looks the easyinstall dependency is gone). Of course, the real issue here is that, while Python may come with "batteries included" you only get the common sizes like A, C and D. If you need a B cell, you're on your own. In XML land, validation is one such case. Me, I'd like complete xpath support, and xslt as well. But this happens with other subsystems, like doing client-side SSL support, but not server-side (at least, not as of 2.4; I haven't checked 2.5). If you just want an xml module in the standard library that's more complete, I'd vote for the source distribution of lxml, as that's C + Python and built on top of commonly available libraries. The real issue would be making current lxml work with the "outdated" versions of those libraries found in current OS distributions. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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 XML Validator
On Wed, 05 Mar 2008 13:01:14 +1300 Greg Ewing <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > Trying to install it from the repository is a PITA, because > > it uses both the easyinstall and Pyrex > > It shouldn't depend on Pyrex as long as it's distributed > with the generated C files. If it's not, that's an > oversight on the part of the distributor. Sorry I wasn't clear. "from the repository" means building from sourced checked out of the source repository, not from a distribution. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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 XML Validator
On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Mike Meyer <[EMAIL PROTECTED]> wrote: > > On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed > > <[EMAIL PROTECTED]> wrote: > > > lxml is good but not written in python and difficult to install and > > > didn't > > > work > > > on MacOS X. > > lxml is built on top of libxml2/libxslt, which are bundled with most > > Unix-like OS's (including Mac OS X), or available in their package > > systems. Trying to install it from the repository is a PITA, because > > it uses both the easyinstall and Pyrex (later Cython) packages - which > > aren't bundled with anything. On the other hand, if it's in the > > package system (I no longer have macports installed anywhere, but > > believe it was there at one time), that solves all those problems. I > > believe they've excised the easyinstall source dependencies, though. > [...] > > If you just want an xml module in the standard library that's more > > complete, I'd vote for the source distribution of lxml, as that's C + > > Python and built on top of commonly available libraries. The real > > issue would be making current lxml work with the "outdated" versions > > of those libraries found in current OS distributions. > > I'm not sure what you perceive to be the problems with easy_install on > OSX; I find it makes life *much* simpler for managing python packages. I don't, but the real issue is that it's been considered - and rejected - for inclusion in the standard library multiple times. The OPs request was for a validating XML parser in the standard library. Any third party code that requires easy_install won't be acceptable. I think lxml is the best Python XML library that meets his requirements, and it would make my life a lot easier if it were part of the standard library. However, the authors tend to require recent versions of libxml2 and libxslt, which means recent versions of lxml won't build and/or work with the libraries bundled with many Unix and Unix-like systems - including OSX. Which means you wind up having to build those yourself if you want a recent version of lxml, even if you're using a system that includes lxml in it's package system. > Be that as it may, since the release of lxml 2.0, the project has > updated the lxml website with useful information about source > installations and, in particular, OSX source installations: > > <http://codespeak.net/lxml/build.html> > > IIRC, here's what worked for me on Leopard (10.5.2) using the python.org > 2.5.2, though it should work fine with the Apple-supplied 2.5.1: This is similar to what I went through with 1.3.6 on Tiger, but I used MacPorts. On Leopard, 1.3.6 builds out of the box. Just do "sudo python setup.py install" and you're done. That's probably the easiest way to get a validating xml parser on OS X at this time. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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 XML Validator
On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel <[EMAIL PROTECTED]> wrote: > (weird places these threads come up at, but now that it's here...) > Mike Meyer wrote: > > On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote: > >> In article <[EMAIL PROTECTED]>, > >> Mike Meyer <[EMAIL PROTECTED]> wrote: > >>> On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed > >>> <[EMAIL PROTECTED]> wrote: > >>>> lxml is good but not written in python and difficult to install and > >>>> didn't > >>>> work on MacOS X. Please note that this original complaint is *not* mine. However... > Due to a design problem in MacOS-X, not a problem in lxml. I didn't find it noticeably harder to install lxml on MacOS-X than most other systems. > But it's not that hard to install either, as previous posts presented. Depends on how you define "hard". If I have to create a custom environment with updated version of system libraries just to use lxml, I'd call that "hard". That was pretty much the only route available the first time I wanted lxml on OS-X. And ubuntu. And RHEL. The second time for OS-X, I used an older version of lxml (1.3.6), and just did "setup.py install". Worked like a charm. That's not hard. The only system that installing a modern version of lxml on was easy was FreeBSD, probably because libxml2 and libxslt aren't part of the system software. > > However, the authors tend to require recent > > versions of libxml2 and libxslt, which means recent versions of lxml > > won't build and/or work with the libraries bundled with many Unix and > > Unix-like systems > I wouldn't consider a dependency on an almost three year old library version > "recent", libxml2 2.6.20 was released in July 2005. Well, if you're on a development box that you update regularly, you're right: three years old is pretty old. If you're talking about a production box that you don't touch unless you absolutely have to, you're wrong: three years old is still pretty recent. For example, the most recent release of RHEL is 4.6, which ships with libxml2 2.6.16. > > Which means you wind up having to > > build those yourself if you want a recent version of lxml, even if > > you're using a system that includes lxml in it's package system. > If you want a clean system, e.g. for production use, buildout has proven to be > a good idea. And we also provide pretty good instructions on our web page on > how to install lxml on MacOS-X and what to take care of. Yes, but the proposal was to include it in the Python standard library. Software that doesn't work on popular target platforms without updating a standard system library isn't really suitable for that. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
On Fri, 02 May 2008 00:03:24 - [EMAIL PROTECTED] wrote: > On 11:45 pm, [EMAIL PROTECTED] wrote: > >I like this, except one issue: I really don't like the .local > >directory. I don't see any compelling reason why this needs to be > >~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > >it from view, especially since the user is expected to manage this > >explicitly. > > I've previously given a spirited defense of ~/.local on this list ( > http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) > among other places. > > Briefly, "lib" is not the only directory participating in this > convention; you've also got the full complement of other stuff that > might go into an installation like /usr/local. So, while "lib" might > annoy me a little, "bin etc games include lib lib32 man sbin share src" > is going to get ugly pretty fast, especially if this is what comes up in > Finder or Nautilus or Explorer every time I open a window. You have a problem with 10 directories? Well, ok - if you have that on top of all the clutter that you normally get, yeah, I might object too. On the other hand, if *every* application used those 10 directories - and *only* those 10 directories - for all the files it needed that weren't for user-created data, that would be heaven. The fallacy you're falling into is that users never have to deal with those dot-files (or directories). They do. One of the most common operations when trying to diagnose a misbehaving application is "delete the configuration files" (my favorite is that I fix gnucash printing failures by deleting CUPS config files), and the user has to figure out which, if any, of those magic files need to be deleted. If you're using Finder, you wind up turning on the preference that says "show me those", and suddenly your nice, clean directory explodes into ... Well, here's my home directory, shared between a Mac and a Unix box: mbook-fbsd% cd mbook-fbsd% ls | wc -l 42 mbook-fbsd% ls -d .* | wc -l 174 It's not very clean. Because it's a Mac, it's got some directories that the Mac felt I needed that I really have no use for. And there's maybe a dozen files there that are scratch files from various things I haven't cleaned up yet. Of course, the dot-files are much worse, because I normally don't see them, so there's not incentive to clean them up at all. But if i could trade those 172 (can't lose . and ..) "hidden" .files for 10 visible directories in ~, I'd do it in an instant - even if I didn't already have bin, etc, src & lib directories there. > Put another way - it's trivial to make ~/.local/lib show up by > symlinking ~/lib, but you can't make ~/lib disappear, and lots of > software ends up looking at ~. Just for the record, it's equally trivial - but better - to make ".local" disappear by symlinking '.local' to '.'. But providing an option is even cleaner, and then the fact that you can't use symlink to hide one is moot. As far as I'm concerned, .local is the worst possible choice for this choice for this name. Not only does it wind up in the more cluttered of the two name spaces, it doesn't tell me anything about the application(s) it belongs to, so I have to worry about it pretty much every time I'm mucking about with the config files. .python would be much better - at least I'd know what it was for by the name. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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] Fixing the XML batteries
On Fri, 09 Dec 2011 09:02:35 +0100 Stefan Behnel wrote: > a) The stdlib documentation should help users to choose the right > tool right from the start. > b) cElementTree should finally loose it's "special" status as a > separate library and disappear as an accelerator module behind > ElementTree. +1 and +1. I've done a lot of xml work in Python, and unless you've got a particular reason for wanting to use the dom, ElementTree is the only sane way to go. I recently converted a middling-sized app from using the dom to using ElementTree, and wrote up some guidelines for the process for the client. I can try and shake it out of my clients lawyers if it would help with this or others are interested. http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, 9 Dec 2011 21:26:29 +0100 Cedric Sodhi wrote: > Readable code, is it really an advantage? > Of course it is. Ok, you got that right. > Forcing the programmer to write readable code, is that an advantage? > No suspense, the answer is Of course not. This is *not* an "Of course". Readable code is *important*. Giving programmers more power in exchange for less readable code is a bad trade. For an extended analsysis, see: http://blog.mired.org/2011/10/more-power-is-not-always-good-thing.html One of Python's best points is that the community resists the urge to add things just to add things. The community generally applies three tests to any feature before accepting it: 1) It should have a good use case. 2) It should enable more readable code for that use case. 3) It shouldn't make writing unreadable code easy. DB fails all three of these tests. It doesn't have a good use case. The code you create using it is not more readable than the alternative. And it definitely makes writing unreadable code easy. And of course, it violates TOOWTDI. http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone still using Python 2.5?
On Thu, 22 Dec 2011 01:49:37 + Michael Foord wrote: > These figures can't possibly be true. No-one is using Python 3 yet. ;-) Since you brought it up. Is anyone paying people (or trying to hire people) to write Python 3? Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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] Proposed PEP on concurrent programming support
PEP: XXX Title: Interpreter support for concurrent programming Version: $Revision$ Last-Modified: $Date$ Author: Mike Meyer Status: Draft Type: Informational Content-Type: text/x-rst Created: 11-Nov-2011 Post-History: Abstract The purpose of this PEP is to explore strategies for making concurrent programming in Python easier by allowing the interpreter to detect and notify the user about possible bugs in concurrent access. The reason for doing so is that "Errors should never pass silently". Such bugs are caused by allowing objects to be accessed simultaneously from another thread of execution while they are being modified. Currently, python systems provide no support for such bugs, falling back on the underlying platform facilities and some tools built on top of those. While these tools allow prevention of such modification if the programmer is aware of the need for them, there are no facilities to detect that such a need might exist and warn the programmer of it. The goal is not to prevent such bugs, as that depends on the programmer getting the logic of the interactions correct, which the interpreter can't judge. Nor is the goal to warn the programmer about any such modifications - the goal is to catch standard idioms making unsafe modifications. If the programmer starts tinkering with Python's internals, it's assumed they are aware of these issues. Rationale = Concurrency bugs are among the hardest bugs to locate and fix. They result in corrupt data being generated or used in a computation. Like most such bugs, the corruption may not become evident until much later and far away in the program. Minor changes in the code can cause the bugs to fail to manifest. They may even fail to manifest from run to run, depending on external factors beyond the control of the programmer. Therefore any help in locating and dealing with such bugs is valuable. If the interpreter is to provide such help, it must be aware of when things are safe to modify and when they are not. This means it will almost certainly cause incompatible changes in Python, and may impose costs so high for non-concurrent operations as to make it untenable. As such, the final options discussed are destined for Python version 4 or later, and may never be implemented in any mainstream implementation of Python. Terminology === The word "thread" is used throughout to mean "concurrent thread of execution". Nominally, this means a platform thread. However, it is intended to include any threading mechanism that allows the interpreter to change threads between or in the middle of a statement without the programmer specifically allowing this to happen. Similarly, the word "interpreter" means any system that processes and executes Python language files. While this normally means cPython, the changes discussed here should be amenable to other implementations. Concept === Locking object -- The idea is that the interpreter should indicate an error anytime an unlocked object is mutated. For mutable types, this would mean changing the value of the type. For Python class instances, this would mean changing the binding of an attribute. Mutating an object bound to such an attribute isn't a change in the object the attribute belongs to, and so wouldn't indicate an error unless the object bound to the attribute was unlocked. Locking by name --- It's also been suggested that locking "names" would be useful. That is, to prevent a specific attribute of an object from being rebound, or a key/index entry in a mapping object. This provides a finer grained locking than just locking the object, as you could lock a specific attribute or set of attributes of an object, without locking all of them. Unfortunately, this isn't sufficient: a set may need to be locked to prevent deletions for some period, or a dictionary to prevent adding a key, or a list to prevent changing a slice, etc. So some other locking mechanism is required. If that needs to specify objects, some way of distinguishing between locking a name and locking the object bound to the name needs to be invented, or there needs to be two different locking mechanisms. It's not clear that the finer grained locking is worth adding yet another language mechanism. Alternatives Explicit locking These alternatives requires that the programmer explicitly name anything that is going to be changed to lock it before changing it. This lets the interpreter gets involved, but makes a number of errors possible based on the order that locks are applied. Platform locks '''''''''''''' The current tool set uses platform locks via a C extension. The problem with these is that the interpreter has no knowledge of them, and so can't do anything about d
Re: [Python-Dev] A question about the subprocess implementation
On Sat, 7 Jan 2012 21:25:37 + (UTC)
Vinay Sajip wrote:
> The subprocess.Popen constructor takes stdin, stdout and stderr keyword
> arguments which are supposed to represent the file handles of the child
> process.
> The object also has stdin, stdout and stderr attributes, which one would
> naively
> expect to correspond to the passed in values, except where you pass in e.g.
> subprocess.PIPE (in which case the corresponding attribute would be set to an
> actual stream or descriptor).
>
> However, in common cases, even when keyword arguments are passed in, the
> corresponding attributes are set to None. The following script
Note that this is documented behavior for these attributes.
> This seems to me to contradict the principle of least surprise. One
> would expect, when an file-like object is passed in as a keyword
> argument, that it be placed in the corresponding attribute.
Since the only reason they exist is so you can access your end of a
pipe, setting them to anything would seem to be a bug. I'd argue that
their existence is more a pola violation than them having the value
None. But None is easier than a call to hasattr.
> That way, if one wants to do p.stdout.close() (which is necessary in
> some cases), one doesn't hit an AttributeError because NoneType has
> no attribute 'close'.
You can close the object you passed in if it wasn't PIPE. If you
passed in PIPE, the object has to be exposed some way, otherwise you
*can't* close it.
This did raise one interesting question, which will go to ideas...
http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> import os
> from subprocess import Popen, PIPE
> import tempfile
>
> cmd = 'ls /tmp'.split()
>
> p = Popen(cmd, stdout=open(os.devnull, 'w+b'))
> print('process output streams: %s, %s' % (p.stdout, p.stderr))
> p = Popen(cmd, stdout=tempfile.TemporaryFile())
> print('process output streams: %s, %s' % (p.stdout, p.stderr))
>
> prints
>
> process output streams: None, None
> process output streams: None, None
>
> under both Python 2.7 and 3.2. However, if subprocess.PIPE is passed in, then
> the corresponding attribute *is* set: if the last four lines are changed to
>
> p = Popen(cmd, stdout=PIPE)
> print('process output streams: %s, %s' % (p.stdout, p.stderr))
> p = Popen(cmd, stdout=open(os.devnull, 'w+b'), stderr=PIPE)
> print('process output streams: %s, %s' % (p.stdout, p.stderr))
>
> then you get
>
> process output streams: ', mode 'rb' at 0x2088660>, None
> process output streams: None, ', mode 'rb' at 0x2088e40>
>
> under Python 2.7, and
>
> process output streams: <_io.FileIO name=3 mode='rb'>, None
> process output streams: None, <_io.FileIO name=5 mode='rb'>
>
> This seems to me to contradict the principle of least surprise. One would
> expect, when an file-like object is passed in as a keyword argument, that it
> be
> placed in the corresponding attribute. That way, if one wants to do
> p.stdout.close() (which is necessary in some cases), one doesn't hit an
> AttributeError because NoneType has no attribute 'close'.
>
___
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] A question about the subprocess implementation
On Sun, 8 Jan 2012 02:06:33 + (UTC) Vinay Sajip wrote: > Mike Meyer mired.org> writes: > > > Since the only reason they exist is so you can access your end of a > > pipe, setting them to anything would seem to be a bug. I'd argue that > > their existence is more a pola violation than them having the value > > None. But None is easier than a call to hasattr. > > I don't follow your reasoning, re. why setting them to a handle used for > subprocess output would be a bug - it's logically the same as the PIPE case. No, it isn't. In the PIPE case, the value of the attributes isn't otherwise available to the caller. I think you're not following because you're thinking about what you want to do with the attributes: > storing it [the fd] in proc.stdout or proc.stderr? As opposed to what they're used for, which is communicating the fd's created in the PIPE case to the caller. Would you feel the same way if they were given the more accurate names "pipe_input" and "pipe_output"? > > You can close the object you passed in if it wasn't PIPE. If you > > passed in PIPE, the object has to be exposed some way, otherwise you > > *can't* close it. > Yes, I'm not disputing that I need to keep track of it - just that proc.stdout > seems a good place to keep it. I disagree. Having the proc object keep track of these things for you is making it more complicated (by the admittedly trivial change of assigning those two attributes when they aren't used) so you can make your process creation code less complicated (by the equally trivial change of assigning the values in those two attributes when they are used). Since only the caller knows when this complication is needed, that's the logical place to put it. > That way, the closing code can be de-coupled from the code that sets > up the subprocess. There are other ways to do that. It's still the same tradeoff - you're making the proc code more complicated to make the calling code simpler, even though only the calling code knows if that's needed. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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] Proposed PEP on concurrent programming support
On Wed, 4 Jan 2012 00:07:27 -0500 PJ Eby wrote: > On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote: > > A suite is marked > > as a `transaction`, and then when an unlocked object is modified, > > instead of indicating an error, a locked copy of it is created to be > > used through the rest of the transaction. If any of the originals > > are modified during the execution of the suite, the suite is rerun > > from the beginning. If it completes, the locked copies are copied > > back to the originals in an atomic manner. > I'm not sure if "locked" is really the right word here. A private > copy isn't "locked" because it's not shared. Do you have a suggestion for a better word? Maybe the "safe" state used elsewhere? > > For > > instance, combining STM with explicit locking would allow explicit > > locking when IO was required, > I don't think this idea makes any sense, since STM's don't really > "lock", and to control I/O in an STM system you just STM-ize the > queues. (Generally speaking.) I thought about that. I couldn't convince myself that STM by itself sufficient. If you need to make irreversible changes to the state of an object, you can't use STM, so what do you use? Can every such situation be handled by creating "safe" values then using an STM to update them? 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 408 -- Standard library __preview__ package
Antoine Pitrou wrote: >On Sat, 28 Jan 2012 13:14:36 -0500 >Barry Warsaw wrote: >> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote: >> >> >So I do not support the __preview__ package. I think we're better >off >> >flagging experimental modules in the docs than in their name. For >the >> >specific case of the regex module, the best way to adoption may just >> >be to include it in the stdlib as regex and keep it there. Any other >> >solution will just cause too much anxiety. >> >> +1 >> >> What does the PEP give you above this "simple as possible" solution? > >"I think we'll just see folks using the unstable APIs and then >complaining when we remove them, even though they *know* *upfront* that >these APIs will go away." > >That problem would be much worse if some modules were simply marked >"experimental" in the doc, rather than put in a separate namespace. >You will see people copying recipes found on the internet without >knowing that they rely on unstable APIs. How. About doing them the way we do depreciated modules, and have them spit warnings to stderr? Maybe add a flag and environment variable to disable that. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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 408 -- Standard library __preview__ package
Antoine Pitrou wrote: >Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit : >> Antoine Pitrou wrote: >> >You will see people copying recipes found on the internet without >> >knowing that they rely on unstable APIs. >> >> How. About doing them the way we do depreciated modules, and have >them >> spit warnings to stderr? Maybe add a flag and environment variable >to >> disable that. > >You're proposing that new experimental modules spit warnings when you >use them? To be explicit, when the system loada them. > I don't think that's a good way of promoting their use :) And importing something from __preview__or __experimental__or whatever won't? This thread did include the suggestion that they go into their final location instead of a magic module. >(something we do want to do even though we also want to convey the idea >that they're not yet "stable" or "fully approved") Doing it with a message pointing at the page describing the status makes sure users read the docs before using them. That solves the problem of using them without realizing it. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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] requirements for moving __import__ over to importlib?
On Thu, 9 Feb 2012 14:19:59 -0500 Brett Cannon wrote: > On Thu, Feb 9, 2012 at 13:43, PJ Eby wrote: > > Again, the goal is fast startup of command-line tools that only use a > > small subset of the overall framework; doing disk access for lazy imports > > goes against that goal. > > > Depends if you consider stat calls the overhead vs. the actual disk > read/write to load the data. Anyway, this is going to lead down to a > discussion/argument over design parameters which I'm not up to having since > I'm not actively working on a lazy loader for the stdlib right now. For those of you not watching -ideas, or ignoring the "Python TIOBE -3%" discussion, this would seem to be relevant to any discussion of reworking the import mechanism: http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801.html http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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
