Re: [Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote: Nick Coghlan gmail.com> writes: I *think* the 2.x system had an internal buffer that was used by the file iterator, but not by the file methods. With the new IO stack for 3.0, there is now a common buffer shared by all the file operations (including iteration). However, given that the lifting of the restriction is currently undocumented, I wouldn't want to see a commitment to keeping it lifted until we know that it won't cause any problems for the io-in-c rewrite for 3.1 (hopefully someone with more direct involvement with that rewrite will chime in, since they'll know a lot more about it than I do). As you said, there is no special buffering for the file iterator in 3.x, which means the restriction could be lifted (actually there is nothing relying on this restriction in the current code, except perhaps the "telling" flag in TextIOWrapper). Currently I have python (2.x) code that uses 'readline' instead of 'for x in myfile' in order to avoid the 'for' buffering (ie: be presented with the next line as soon as it is written to the other end of a pipe, instead of waiting for the buffer to fill). Does "no special buffering" mean that 'for' doesn't use a read-ahead buffer in p3k, or that readline does use such a buffer, because the latter could make my code break unexpectedly when porting to p3k. --RDM ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, 18 Feb 2009 at 20:31, Guido van Rossum wrote: On Wed, Feb 18, 2009 at 6:38 PM, wrote: On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote: Nick Coghlan gmail.com> writes: I *think* the 2.x system had an internal buffer that was used by the file iterator, but not by the file methods. With the new IO stack for 3.0, there is now a common buffer shared by all the file operations (including iteration). However, given that the lifting of the restriction is currently undocumented, I wouldn't want to see a commitment to keeping it lifted until we know that it won't cause any problems for the io-in-c rewrite for 3.1 (hopefully someone with more direct involvement with that rewrite will chime in, since they'll know a lot more about it than I do). As you said, there is no special buffering for the file iterator in 3.x, which means the restriction could be lifted (actually there is nothing relying on this restriction in the current code, except perhaps the "telling" flag in TextIOWrapper). Currently I have python (2.x) code that uses 'readline' instead of 'for x in myfile' in order to avoid the 'for' buffering (ie: be presented with the next line as soon as it is written to the other end of a pipe, instead of waiting for the buffer to fill). Does "no special buffering" mean that 'for' doesn't use a read-ahead buffer in p3k, or that readline does use such a buffer, because the latter could make my code break unexpectedly when porting to p3k. Have a look at the code in io.py (class TextIOWrapper): http://svn.python.org/view/python/branches/py3k/Lib/io.py?view=log I believe it doesn't force reading ahead more than necessary. If a single low-level read() returns enough data to satisfy the __next__() or readline() (or it can be satisfied from data already buffered) then it won't force reading more. Hmm. I'm not sure I'm reading the code right, but it looks from the docstrings like TextIOWrapper expects to read from a BufferedIOBase object, whose doc string contains this comment: If the argument is positive, and the underlying raw stream is not 'interactive', multiple raw reads may be issued to satisfy the byte count (unless EOF is reached first). But for interactive raw streams (XXX and for pipes?), at most one raw read will be issued, and a short result does not imply that EOF is imminent. Since the 'pipe' comment is an XXX, it is not clear that my use case is covered. However, the actual implementation of readinto seems to only call 'read' once, so as long as the 'read' of the subclass returns whatever bytes are available, then it looks good to me :) Since TextIOWrapper is careful to call 'read1' on the wrapped buffer object, and the one place that 'read1' has a docstring clearly indicates that it does at most one read and returns whatever data is ready, it seems that the _intent_ of the code is as you expressed. I'm a python programmer first, and my C is pretty rusty, so I'm not sure if I'm up to looking through the new C code to see how this got translated. I'm thinking that both my use case (and in my case 'for' should now work for me) and the OP's are the way it is intended to work, but documentation of this seems like it would be a good idea. Since the OP doesn't seem to have opened a ticket, I did so: http://bugs.python.org/issue5323. As I said there, I'm willing to work on doc and test patches if this is the behavior the io library is required to have in 3.x. --RDM ___ 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] IO implementation: in C and Python?
On Thu, 19 Feb 2009 at 21:41, Benjamin Peterson wrote: As we prepare to merge the io-c branch, the question has come up [1] about the original Python implementation. Should it just be deleted in favor C version? The wish to maintain the two implementations together has been raised on the basis that Python is easier to experiment on and read (for other vm implementors). I'm personally +0 on this, but I note that it is easier to read not just for other vm implementors, but for users. Witness the question about the behavior of 'for' vs 'readline'. I'd have had a much harder time figuring out the behavior if I'd had to read the C code. That said, I'm not personally sure if maintaining both versions is worth it. Real python developers should make that decision :) --RDM ___ 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 suggestion: Do proto-PEPs in Google Docs
On Sat, 21 Feb 2009 at 12:56, Stephen J. Turnbull wrote: (4) automatic saves of intermediate work -- at the tweak stage, the effort to save, commit, and push to a DVCS outweighs the effort to tweak, costing a lot of polish IME -- wikis don't do this, and I wonder whether people would be willing to save unpolished work, or leave it sitting in the browser "until later" Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM ___ 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 suggestion: Do proto-PEPs in Google Docs
On Sat, 21 Feb 2009 at 01:12, Jeff Hall wrote: Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM That's funny because I would expect that for most people it's the exact opposite... just create a gmail account... boom, done... I'm not necessarily advocating that but just saying that IMO, most people will find google docs to be the "fastest" and "easiest" solution. The ease of creating a gmail account has nothing to do with the point to which I was responding (context which is lost from your reply). That's setup. I was responding to a point talking about in-the-moment workflow. A browser and a GUI javascript program are slower than a unix command line based editor such as vim or emacs both to open up and to use. Thus for me, by using a script to automate the part that the OP suggested would slow the dvcs user down (the update/commit/push cycle), I make the dvcs in-the-moment workflow much faster _for me_ than Google Docs. As I said it's a matter of personal style. Some people _will_ find Google Docs easier and more productive than a dvcs. My point was that not all people will. --RDM ___ 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] Adding PEP consistent aliases for names that don't currently conform
On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote: On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: > > PS.: so is datetime.datetime a builtin then? :) > > Another historic accident. Like socket.socket. :-( > A pity this stuff wasn't addressed for 3.0. Way too late now, though. It may be too late to rename the existing accidents, but why not add consistently-named aliases (socket.Socket, datetime.DateTime, etc) and strongly encourage their use in new code? As a user I'd be +1 on that. In fact, I might even start using 'as' in my own code for that purpose right now. I've always felt vaguely confused and disturbed whenever I imported 'datetime', but until this discussion I didn't realize why :) Thinking about it, I know I've written 'from datetime import DateTime' a number of times and then had to go back and fix my code when I tried to run it. And I'm sure that sometimes when that happens I've had to (re)read the docs (or do a 'dir') to find out why my import wasn't working. Having said all that out loud, I think I might be stronger than a +1 on this idea. I'd be willing to help with doc and even code patches once I finish learning how to contribute properly. --RDM___ 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 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, 4 Mar 2009 at 23:37, Lie Ryan wrote:
Steve Holden wrote:
Raymond Hettinger wrote:
> > > Perhaps the terminology should be
> > >
> > >ordereddict -- what we have here
> > >
> > >sorteddict -- hypothetical future type that keeps
> > > itself sorted in key order
> +1
>
>
> > FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
> Issues:
> * The popitem() method is LIFO.
> * In a non-popping context, there is no OUT. It just stores.
> * FIFO is more suggestive of queue behavior which does not apply here.
> * Stores to existing keys don't go at the end; they leave the order
> unchanged.
>
> FWIW, PEP 372 has links to seven other independent implementations and
> they all have names that are some variant spelling OrderedDict except
> for one which goes by the mysterious name of StableDict.
>
> Am still +1 on painting the class green with pink polka dots, but I'm
> starting to appreciate why others are insisting on pink with green polka
> dots ;-)
>
historydict?
agedict?
I actually like StableDict best. When I hear that I think, "ah, the
key order is stable in the face of insertions, unlike a regular dict".
Nor can I at the moment think of an alternative explanation of what a
"StableDict" might be.
That said, I have no problem with keeping OrderedDict as the name.
("Ordered does not mean sorted, it means insertion order preserving"
may become a FQA (Frequent Question Answer :), but it is short and
clear and takes no longer than explaining what a StableDict _is_.)
Although, that might be another argument in favor of StableDict: since
unless you think what I wrote above you aren't going to have a clue what
it is, someone reading code and encountering it would be more likely to
look it up, whereas with OrderedDict someone is more likely to assume they
know what it is and get confused for a little while before looking it up.
Do I feel strongly enough about this to write a patch? No :)
--RDM
___
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] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)
On Fri, 6 Mar 2009 at 20:57, "Martin v. L??wis" wrote: If it is possible for a hostile outsider to trigger the DOS by sending mail to be processed by an application using the library, and the application can't avoid the DOS without ditching / forking / monkeypatching the library, then I would call the bug a "security bug", period. IIUC, it would have been straight forward for the mail servers to avoid the DOS: simply truncate log lines to 1024 bytes, or something. I believe that in general things that allow DOS attacks to be staged are considered security vulnerabilities by the general security community, albeit of lower priority than exploits. I believe the logic is that one would prefer the system administrator not to have to figure out what caused the DOS and how fix it after getting hit by it and having had a service outage as a result. Normally the "vendor" of package with the DOS vulnerability would provide a fix and push it out, and a conscientious sysadmin would install the "security release" and thus be protected. In this case the application vendor can only fix the DOS bug by modifying the library, and that would fix it only for that application. The logical place to fix it is at the source: the library in question. But since a DOS is lower priority from a security standpoint, I can see the argument for not burdening the release maintainer with anti-DOS patches. We probably should leave it to the release maintainer to decide based on some assessment of the likely impact of not fixing it. Which means it might not get fixed, but that's the reality of limited development and maintenance resources. --RDM___ 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] Belated introduction
I've been watching the threads about tracker maintenance and patch review with interest. I'm afraid that I did not follow the list recommendation to introduce myself when I first started posting, partly because I initially jumped in on something that was a bit of a hot button issue for me :) So, a little belatedly, here is my intro. I've been coding in and loving Python since 1993 or thereabouts. I am currently an independent IT consultant, with specialization in IP networking (especially Cisco), Lunix and Unix system administration, and systems integration. It is in my systems integration work that I make heavy use of Python, writing scripts and programs to tie systems together and/or add needed functionality. In my previous life I was Director of Technology for an ISP, and at one stage we were heavy into web site development. At that time I worked with the Zope community quite a bit, and made some contributions to the beginnings of Zope3. So for at least a few people this might be more of a re-introduction. I've decided that this year I would like to get more involved in the Python community. As another poster said, I'm looking forward to the opportunity to work with and learn from some very smart people. And then there's the satisfaction of giving back to a community that has given me so much over the years, by producing such a delightful language in which to do my coding. So, I've been reading the developer docs, setting up a bzr checkout, learning how to compile a debug python and run tests, wandering around in the source code, etc, etc. My thought about how I could best contribute at the present time is to help out with reviewing tracker issues. I actually updated the open tracker issue with the oldest last activity date this morning, as a sort of trial run. Unless someone wants to suggest a different way for me to contribute (I'm open to any suggestions), I'll probably continue through the list in reverse order of last update date and cherry pick things that interest me and that I think I can make some sort of contribution to. Don't hesitate to let me know if I miss etiquette points (gently, please :). Oh, and I'll be at pycon this year (my second pycon, the first was several years back), and look forward to hanging out with a cool bunch of people :) --RDM ___ 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] Belated introduction
On Sat, 7 Mar 2009 at 08:42, Aahz wrote: On Sat, Mar 07, 2009, rdmur...@bitdance.com wrote: So, a little belatedly, here is my intro. [...] --RDM Welcome! You apparently haven't set your $NAME nor listed a name in your .sig, so how do you prefer to be addressed? Or do you just prefer your initials, like RMS? ;-) Thanks. Initials is fine, but I'm more used to 'David' as form of address. I have been using my initials in my sig because there are just too many Davids around. I suppose changing my sig to my name and my website wouldn't be be a bad thing, so... -- R. David Murray http://www.bitdance.com ___ 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-3.0, unicode, and os.environ
On Fri, 5 Dec 2008 at 12:11, Guido van Rossum wrote: On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi <[EMAIL PROTECTED]> wrote: Guido van Rossum wrote: On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote: In 99% of all cases, using the default encoding will work and do what people expect, which is why I would make this conversion automatic. In all other cases, it will at least not fail silently (which would lead to garbage and data loss) and allow more sophisticated applications to handle it. I think the "always fail noisily" approach isn't the best approach. E.g. if I am globbing for *.py, and there's an undecodable .txt file in a directory, its presence shouldn't cause the glob to fail. But why should it make glob() fail? This sounds like an implementation detail of glob. Glob was just an example. Many use cases for directory traversal couldn't care less if they see *all* files. I agree with Toshio. The only use case I can think of for not seeing all files is when selecting a subset, and if the thing that does the selecting only generates a traceback if a file that falls into the subset is undecodable, then I don't see a problem. That is, if I'm selecting a subset of the files in a directory, and one of that subset is undecodable, I _want_ a traceback, because I'll be wanting _all_ of the files that match my selection criteria.(*) So I'm curious to hear your use cases where undecodable files are "don't care". (*) More specifically, I want the program of a developer who didn't think about the fact that users might have files with undecodable filenames in their directory to generate a traceback rather than silently losing those files. (This is spoken to both by the principle of least surprise and the zen rule that errors should never pass silently :) --RDM ___ 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-3.0, unicode, and os.environ
On Sat, 6 Dec 2008 at 13:06, Steven D'Aprano wrote: Applications can deal with such weird file names. KDE's file manager (konqueror) and file selection dialog both show the character as a small square, presumably the font's missing character glyph, and KDE apps can open and save the file. Still speaking as a user, I think it is quite reasonable to expect applications to deal with undisplayable filenames: displaying the name and opening the file are orthogonal Agreed. I would file a bug report if an application couldn't handle a file that validly exists in my file system, no matter how broken the filename might appear to be. concepts, although I accept that command-line interfaces will have difficulty with file names that can't be typed by the user! Difficult, but not impossible: tab completion in the shell can allow the user to submit otherwise difficult to type filenames to a program. Which means python should be able to handle such things in argument strings, so that my python utilities can manipulate such files when specified as command line argumentsand a sensible error should be generated by default if the program hasn't been written in such a way that it can handle such input. It would be wonderful if all Unix variants would switch to all UTF-8 (I have done so on my own machines...I think :). But it is a slow process. --RDM ___ 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-3.0, unicode, and os.environ
On Sun, 7 Dec 2008 at 13:33, Guido van Rossum wrote: My problem with raising exceptions *by default* when an undecodable name exists is that it may render an app completely useless in a situation where the developer is no longer around. This happened all I think Nick Coghlan's suggestion of emitting warnings would be an excellent solution that addresses both your concerns and the concerns Toshio has expressed (and with which I agree 100%). The above is the only use case I've heard in this thread for ignoring files with names that can't be decoded: so that a user can use the program on those files whose names can be decoded even when the user does not have the resources to get the program fixed to handle undecodable filenames. I agree that that is a worthwhile goal. If warnings were emitted, then files would not be silently ignored, yet the program could still be used. --RDM PS: I'd like to see a similar warning issued when an access attempt is made through os.environ to a variable that cannot be decoded. ___ 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-3.0, unicode, and os.environ
On Mon, 8 Dec 2008 at 13:16, Terry Reedy wrote: And the decoding problems don't pass silently either - they just get emitted as a warning by default instead of causing the application to crash. Do they get automatically logged? In any case, the errors parameter has an in between option to neither ignore or raise but to replace and give *something* printable. This situation seems like an ideal situation for a parameter which gives the application program who uses Python a range of options to working with an un-ideal world. I am really flabbergasted why there is so much opposition to doing so in favor of more difficult or less functional alternatives. I'm in favor of an option to control what happens. I just really really don't want the _default_ to be "ignore". Defaulting to a warning is fine with me, as would be defaulting to a traceback. But defaulting to "silently ignore", as we have now, is just asking for user confusion and debugging headaches, as detailed by Toshio. A _worse_ user experience, IMO, than having a program fail when undecodable filenames match the selection criteria. --RDM ___ 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-3.0, unicode, and os.environ
On Mon, 8 Dec 2008 at 11:25, Guido van Rossum wrote: On Mon, Dec 8, 2008 at 10:34 AM, <[EMAIL PROTECTED]> wrote: I'm in favor of an option to control what happens. I just really really don't want the _default_ to be "ignore". Defaulting to a warning is fine with me, as would be defaulting to a traceback. But defaulting to "silently ignore", as we have now, is just asking for user confusion and debugging headaches, as detailed by Toshio. A _worse_ user experience, IMO, than having a program fail when undecodable filenames match the selection criteria. Do you really not care about the risk where apps that weren't written to be prepared to handle this will be rendered completely useless if a single file in a directory has an unencodable name? This is similar to an issue that Python had for a long time where it wouldn't start up if the current directory contained non-ASCII characters. No, I do care. In another message I agreed with you that having the ap not fail was a reasonable goal. What I'm saying is that having it ignore the undecodable files fail _silently_ is bad. And not picking up a file that matches some selection criteria (ex: *.py) because it is undecodable is a _failure_, in my opinion, that is _worse_ than getting a traceback because there's an undecodable file in the directory. But I'm happy with just issuing a warning by default. That would mean it doesn't fail silently, but neither does it crash. Seems like the best compromise with the broken nature of the real world IT environment. Given that most developers will not have this issue in their own environment, most apps will not be prepared for this issue, and that makes it worse for the app's user! It is exactly because most developers won't have the issue in their own environment that ignoring files silently is a problem. If they did, they'd fix their code before it went out the door. Since they don't, when their code is used by somebody in a mixed encoding environment, the programs _will_ fail by ignoring files that they should process. The question, it seems to me, is do they fail silently and mysteriously by failing to process files they are supposed to, or do they fail with at least a little bit of noise? --RDM ___ 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] RELEASED Python 3.0 final
On Sat, 6 Dec 2008 at 20:19, [EMAIL PROTECTED] wrote: On 05:54 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 9:28 PM, <[EMAIL PROTECTED]> wrote: Whenever someone asks me which version to use, I alwasys respond with a question -- what do you want to use it for? In the longer term, I think that you should look at this as a symptom of a problem. If you learn Java, you learn the most recent version. If you need your software to work with an older version, you just pass a special option Sometimes this even works. But it isn't always easy to get it right, and if you are mixing librarieswell, in my real-world experience we wound up upgrading the VM. to the compiler. If you want your *old* software to work with a *new* version, it basically just does (at least, 99% of the time). If you specify the source option correctly. It seems to me that 3to2 and 2to3 are the python equivalent to the javac 'target' and 'source' options. Like Guido said, the python community just doesn't have the resources to make them perfect :(. Based on a quick google, the Java community appears to be grappling with these same issues: http://blog.adjective.org/post/2008/02/21/Java-Backwards-Compatability the poster seems intent on maintaining more backward compatibility than we have with python2/3, until you remember that java uses a compile-and-distribute-binaries paradigm and python does not. Once you realize that, the differences in backward compatibility don't seem so large...at least to me. --RDM ___ 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 wart which should have been repaired in 3.0?
On Tue, 30 Dec 2008 at 17:51, Phillip J. Eby wrote: At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote: More trouble with the "just take the dirname": paths = ['/a/b/c', '/a/b/d', '/a/b'] os.path.dirname(os.path.commonprefix([ os.path.normpath(p) for p in paths])) give '/a', not '/a/b'. ...because that's the correct answer. But not the answer that is wanted. So the challenge now is to write a single expression that will yield '/a/b' when passed the above paths list, and also produce '/a/b' when passed the following paths list: paths = ['/a/b/c', '/a/b/cd'] --RDM ___ 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 wart which should have been repaired in 3.0?
On Tue, 30 Dec 2008 at 21:30, rdmur...@bitdance.com wrote: On Tue, 30 Dec 2008 at 17:51, Phillip J. Eby wrote: At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote: > More trouble with the "just take the dirname": > > paths = ['/a/b/c', '/a/b/d', '/a/b'] > os.path.dirname(os.path.commonprefix([ > os.path.normpath(p) for p in paths])) > > give '/a', not '/a/b'. ...because that's the correct answer. But not the answer that is wanted. So the challenge now is to write a single expression that will yield '/a/b' when passed the above paths list, and also produce '/a/b' when passed the following paths list: paths = ['/a/b/c', '/a/b/cd'] Sorry, now I see what you are saying: that in '/a/b' the 'b' is the filename. Clearly that wasn't what I intuitively expected our notional 'commonpathprefix' command to produce, for whatever that is worth :) --RDM ___ 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] py3k: TypeError: object.__init__() takes no parameters
On Fri, 16 Jan 2009 at 16:53, Nick Craig-Wood wrote: [snip] Perhaps 2.5's object.__init__ just swallowed all args, thus hiding bogus calls. Yes it did which is the fundamental difference in behaviour between py2 and py3 as far as I can see. Actually, between py<=2.5 and py>=2.6. --RDM ___ 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 3142: Add a "while" clause to generator expressions
On Tue, 20 Jan 2009 at 16:56, Antoine Pitrou wrote: Alexey G. Shpagin udmvt.ru> writes: Example will look like g = (n for n in range(100) if n*n < 50 or else_break()) Please don't suggest any hack involving raising StopIteration as part of a conditional statement in a generator expression. It might work today, but it might as well break tomorrow as it's only a side-effect of the implementation, not an official property of the language. Doing the above is, by definition, no different from raising StopIteration in a for loop inside a generator function. The language reference does document the raising of a StopIteration as signaling the exhaustion of the generator. In addition, the 3.0 docs (but, oddly, not the 2.6 docs) say in the 'for' loop documentation: "When the items are exhausted (which is immediately when the list is empty or an iterator raises a StopIteration exception)"). The difference in behavior between raising StopIteration in a list comprehension versus a generator expression are consistent with the above, by the way. If you raise StopIteration in a function whose definition is the same as the list comprehension but you are building the list as you go and only returning it when it is complete, then the StopIteration would propagate upward with no values returned (ie: in a for loop it would look like an empty list). I don't know about other people, but I have certainly assumed that raising StopIteration was a legitimate way to terminate an iterator, and have written code accordingly. If this is not true, it should probably be explicitly documented in the language reference somewhere. --RDM ___ 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 3142: Add a "while" clause to generator expressions
On Wed, 21 Jan 2009 at 21:46, Steven D'Aprano wrote:
On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote:
It is a carefully designed 1 to
1 transformation between multiple nested statements and a single
expression.
I'm sure that correspondence is obvious to some, but it wasn't obvious
to me, and I don't suppose I'm the only one. That's not a criticism of
the current syntax. Far from it -- the current syntax is excellent,
regardless of whether or not you notice that it corresponds to a
if-loop nested inside a for-loop with the contents rotated outside.
It wasn't obvious to me until I read this thread, but now that I know
about it I feel a huge sense of relief. I was never comfortable with
extending (or reading an extension of) a list comprehension beyond the
obvious yield/for/if pattern before. Now I have a reliable tool to
understand any complex list comprehension. I would not want to lose that!
But this proposal ignores and breaks that. Using 'while
x' to mean 'if x: break' *is*, to me, 'ad hoc'.
But it doesn't mean that. The proposed "while x" has very similar
semantics to the "while x" in a while-loop: break when *not* x.
Half right. 'while x' in the proposed syntax is equivalent to 'if not x:
break', But IMO it goes too far to say it has similar semantics to 'while
x' in a while loop. Neither
while x*x<4:
for x in range(10):
yield x*x
nor
for x in range(10):
while x*x<4:
yield x*x
are the same as
for x in range(10):
if not x*x<4: break
yield x*x
I understand that you are saying that 'while x' is used in the same
logical sense ("take a different action when x is no longer true"),
but that I don't feel that that is enough to say that it has similar
semantics. Or, perhaps more accurately, it is just similar enough to be
very confusing because it is also different enough to be very surprising.
The semantics of 'while' in python includes the bit about creating a
loop, and does _not_ include executing a 'break' in the surrounding loop.
To give 'while' this new meaning would be, IMO, un-pythonic. (If python
had a 'for/while' construct, it would be a different story...and then
it would probably already be part of the list comprehension syntax.)
So I detest the proposed change. I find it ugly and anti-Pythonic.
I'd say +1 except that I don't find it ugly, just un-Pythonic :)
--RDM
___
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] __del__ and tp_dealloc in the IO lib
On Fri, 23 Jan 2009 at 11:57, Giovanni Bajo wrote: The fact that file objects are collected and closed immediately in all reasonable use cases (and even in case of exceptions, that you mention, things get even better with the new semantic of the except clause) is a *good* property of Python. I regularly see people *happy* about it. I have never assumed that python closed my files before the end of the program unless I told it to do so, and have always coded accordingly. To do otherwise strikes me as bad coding. I don't believe I ever considered that such an assumption was even thinkable: closing open files when I'm done with them is part of my set of "good programming" habits developed over years of coding, habits that I apply in _any_ language in which I write code. (In fact, it took me a while before I was willing to let python take care of closing the files at program end...and even now I sometimes close files explicitly even in short programs.) Closing file objects is a specific instance of a more general programming rule that goes something like "clean up when you are done". I do in general trust python to clean up python data structures because it knows better than I do when "done" arrives; but when I know when "done" is, I do the cleanup. I love the 'with' statement :) --RDM ___ 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] Should ftplib use UTF-8 instead of latin-1 encoding?
On Fri, 23 Jan 2009 at 21:55, Oleg Broytmann wrote: On Fri, Jan 23, 2009 at 10:15:18AM -0800, Brett Cannon wrote: If I remember correctly something along Martin's comment about 7-bit clean is needed, but some servers don't follow the standard, so I swapped it to Latin-1. But that was so long ago I don't remember where I gleaned the details from in the RFC. If I misread the RFC and it is UTF-8 then all the better to make more of the world move over to Unicode. I don't know any server that encode file names in any way. All servers I know just pass filenames as is, 8-bit; some that implement stricter RFC-959 mangle chr(255), but that's all. One can encounter a server that stores files in a number of different encodings. Given that a Unix OS can't know what encoding a filename is in (*), I can't see that one could practically implement a Unix FTP server in any other way. --RDM (*) remember the earlier extensive discussion of this when the issue of listdir() ignoring non-encodable filesnames came up? ___ 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] Should ftplib use UTF-8 instead of latin-1 encoding?
On Fri, 23 Jan 2009 at 21:23, "Martin v. L?wis" wrote: Given that a Unix OS can't know what encoding a filename is in (*), I can't see that one could practically implement a Unix FTP server in any other way. However, an ftp server is different. It might start up with an empty folder, and receive *all* of its files through upload. Then it can certainly know what encoding the file names have on disk. It *could* also support operation on pre-existing files, e.g. by providing a configuration directive telling the encoding of the file names, or by ignoring all file names that are not encoded in UTF-8. I don't see how starting with an empty directory helps. The filename comes from the client, and the FTP server can't know what the actual encoding of that filename is. --RDM___ 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] Examples in Py2 or Py3
On Thu, 29 Jan 2009 at 10:50, Facundo Batista wrote:
This introduces the problem that some examples are in Py2 and others
are in Py3. Sometimes this is not explicit, and gets confusing. I'm
trying to avoid this confusion when preparing my own examples. So far,
I use (py3) as a prefix for any example block, like:
(Py3k)
(some example)
(some result)
Is there any recommended way to avoid confusion in these cases? (I'm
thinking about changing the prompt in my Python installation, to
something like ">2>>" and ">3>>", to be explicit about it... but I
wanted to know if there's another better way)
My suggestion would be to run the examples in the interpreter shell
to validate them before posting, and just cut and paste the banner
along with the example:
Python 2.6.1 (r261:67515, Jan 7 2009, 17:09:13)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "hello world"
hello world
Python 3.0 (r30:67503, Dec 18 2008, 19:09:30)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello world")
hello world
A bit noisier, but not much more work than cutting and pasting the
example without the banner :)
--RDM
___
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 3.0.1
On Thu, 29 Jan 2009 at 16:43, Raymond Hettinger wrote: On Thu, 29 Jan 2009 at 15:40, Guido van Rossum wrote: Also you could try find shelve users (are there any?) I'm a big fan of shelves and have always used them extensively. Not sure if anyone else cares about them though. I use them. Not in any released products at the moment, though, and I haven't migrated the shelve-using code to 3.0 yet. So I'd be in favor of adding sqlite3 support as soon as practical. --RDM ___ 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
