Re: [Python-Dev] mUTF-7 support?
Jesus Cea j...@jcea.es wrote: On 10/10/14 02:43, Victor Stinner wrote: What is the current behaviour of imaplib in Python 3.4 with non-ASCII characters in mailbox names? It breaks. Crash burn. Oh ok. So in short, imaplib doesn't work on Python 3: Actually, it doesn't work in Python 2 either. It never supported international mailbox names. Correct. I had to hack in mUTF-7 support in getmail to properly support international IMAP users. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support
Christian Heimes li...@cheimes.de wrote: days 32bit signed integer numbers of days since Jan 1, 1 AD in proleptic Gregorian calendar (aka modern civil calendar). That's Rata Die minus one day since it defines Jan 1, 1 AD as day 1. This allows days between year 5.8 Mio in the past and 5.8 Mio in the future ((131) // 365.242 ~ 5879618). nanoseconds --- 64bit signed or unsigned integer more than enough for nanosecond granularity (47bits), we could easily push it to pico seconds resolution (57bits) in the future. An alternate strategy might be to use tai64/tai64n/tai64na, which can represent any time over the course of a few hundred billion years to second/nanosecond/attosecond, respectively. They're well-defined, and there's a fair bit of software that can use or manipulate dates in these formats. tai64 is defined similar to propleptic Gregorian in that it uses an idealized 24*60*60 second day, etc. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Anyone still using Python 2.5?
Michael Foord fuzzy...@voidspace.org.uk wrote: On 21 Dec 2011, at 12:42, Barry Warsaw wrote: FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support) release in April 2012 will have only Python 2.7 (and 3.2). True, but 2.5 is still current on Hardy, an LTS release that is officially supported until April 2013. Lots of places still use 2.5 on Hardy (or on Lucid, the LTS release after Hardy, though they have to get it from the deadsnakes repository as its not the normal version on Lucid). My workplace uses 2.5 for a lot of things, but is slowly transitioning to 2.6. For production work I've been on 2.6 for a while and will soon be switching to 2.7 (I do my development on 2.7). For my libraries I'm still supporting 2.4. My own personal software generally tries to stay compatible further back. getmail is used on lots of little network appliances and such that don't necessarily run a current OS, so getmail v4 targets 2.3.3 and up. If I'm writing something new today, I usually assume 2.6 and up. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
Arc Riley arcri...@gmail.com wrote: +1 on ending with 2.6. That seems precipitous. I'm the maintainer of 3rd party Python 3-only packages and have ported a few modules that we needed with some help from the 2to3 tool. It's really not a big deal - and Py3 really is a massive improvement. The main thing holding back the community are lazy and/or obstinate package maintainers. I wouldn't say that. For instance, I'm just starting a refactoring that will result in getmail v.5, but I need to target Python 2.5 and up, so there's essentially no way the code will run in Python 3.x (as another list member posted). Why do I need to target Python 2.5? Because that's the most current default version of Python shipped in Debian stable and various other distributions that don't stay on the bleeding edge. getmail v.4 targeted Python 2.3 and up, getmail v.3 targeted Python 1.5.2 and up. I may be able to target Python 2.6 in a year or two, at which point Python 3 compatibility becomes a reasonable goal. Saying 2.6 is the last Python 2.x seems to me to be a death sentence for Python 3. People will stay with 2.x much longer than you seem to want them to, and making it harder for them to upgrade will only hurt Python 3. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
Martin v. Löwis mar...@v.loewis.de wrote: I wouldn't say that. For instance, I'm just starting a refactoring that will result in getmail v.5, but I need to target Python 2.5 and up, so there's essentially no way the code will run in Python 3.x (as another list member posted). That's a common myth. It is very well possible, using 2to3. You don't have to wait until you can drop 2.5 to start supporting 3.x, out of a single code base. I haven't tried this, but I was relying on Daniel Stutzbach's opinion posted here earlier: http://mail.python.org/pipermail/python-dev/2009-November/093608.html It's pretty easy to make Python source that works under 2.6 and 3.x. It's basically impossible to make Python source that works under 2.4/2.5 and 3.x. Why do I need to target Python 2.5? Because that's the most current default version of Python shipped in Debian stable and various other distributions that don't stay on the bleeding edge. Are you saying that it doesn't *run* on 2.6? No. getmail v.4 runs fine on Python 2.3.4 through 2.6.x; getmail's code has always been pretty forward-compatible. Why? (not sure what you mean by targetting) By target, I mean backwards compatibility -- the minimum version of Python which is required to run getmail. getmail v.4 came out of beta about five years ago targetting Python 2.3 and higher, and 2.3 was too bleeding-edge for many users -- it wasn't shipped by many Linux distributions for a long time after getmail v.4 was released. Debian *still* shipps getmail v3 (which supports back to Python 1.5.2) today, although they also ship v4. getmail v.5 will be released in a month or three. And many of its users will still have Python 2.5, so that's what getmail has to run on. Perhaps Daniel's comment is incorrect (I have no evidence either way), but if it is true that having a single getmail codebase run on Python 2.5 and Python 3.x is basically impossible, then I won't be too concerned about 3.x for a while yet. I've been an avid Python user and promoter since 1.2, but saying drop Python 2.x and switch to 3 now is simply not realistic in any of the environments in which I use Python daily. My $0.02. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Addition of pyprocessing module to standard lib.
A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? You can test HPUX and VMS with a (free) HP Testdrive account (along with a bunch of Linuxes and *BSDs) on various hardware platforms. I used it extensively when doing portability testing of another project. http://www.testdrive.hp.com/ Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Addition of pyprocessing module to standard lib.
Andrew McNabb [EMAIL PROTECTED] wrote: Think of the processing module as an alternative to the threading module, not as an alternative to MPI. In Python, multi-threading can be extremely slow. The processing module gives you a way to convert from using multiple threads to using multiple processes. Indeed; pyprocessing was exactly what I wanted, and worked exactly as it said it did. It had essentially no learning curve at all because of its implementation of essentially the same interface as the threading module. It's remoting capabilities are almost surplus to requirements; if I wanted that, I might use MPI or something else. If it made people feel better, maybe it should be called threading2 instead of multiprocessing. The word processing seems to make people think of parallel processing and clusters, which is missing the point. threading is to threads as processing is to processes; that's why it was named processing. But the choice of name shouldn't affect the decision as to whether it should be included or not. Anyway, I would love to see the processing module included in the standard library. I would as well; I'm using it in a current project, and can see opportunities for it to be useful in other projects. My only note is that based on my experience, the code needs a little cleanup for portability reasons before it is included with the Python standard library -- it worked fine as-is on Linux, but needed some hackery to get running on a slightly elderly Solaris 8 box. I didn't test it on anything else. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] [OT] Re: getpass and stdin
Shaya Potter [EMAIL PROTECTED] wrote: Leif Walsh wrote: On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter [EMAIL PROTECTED] wrote: the -p PASSWD option is not good on multi user systems the -p PASSFILE option is not particularly good on NFS based systems (have to trust every user on every machine with access to NFS share) You seem somehow both worried about security, yet too lazy to type in your password. I think at some point, one of those concerns is going to have to give. That was exactly what I've been telling this user on the getmail mailing list for the last week. Apologies that he's decided to bother you with it. Charles -- -- Charles Cazabon [EMAIL PROTECTED] Software, consulting, and services available at http://pyropus.ca/ -- ___ 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] Testers wanted: mailbox.py bugfix
A.M. Kuchling [EMAIL PROTECTED] wrote: http://www.python.org/sf/1599254 is a bug in the mailbox.py module that affects single-file mailbox formats (mbox, Babyl, MMDF) and can cause data loss. I can't speak for MMDF or Babyl, but it's a well-known requirement that all programs on a system must use the same type of locking when mbox files are used; the administrator picks his favourite (fcntl, dotlocking, whatever) and then has to ensure all mbox-aware programs are compiled to use that locking style. A proposed fix, mailbox-unified-patch, is attached to the bug. I'm not sure that this actually fixes the problem, but more to the point -- I'm not sure it should try. Any mail admin that deploys multiple mbox-aware programs with different locking methods is shooting themselves in the foot, regardless of whether Python tries to turn it into just a flesh wound... Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] beta1 coming real soon
Thomas Heller [EMAIL PROTECTED] wrote: Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. It*s June 14 no longer in too many parts of the world ;-). Apparently it's still 1999 in some parts of the world. From your message: From: Thomas Heller [EMAIL PROTECTED] To: python-dev@python.org Date: Fri, 31 Dec 1999 23:11:35 +0100 Subject: Re: [Python-Dev] beta1 coming real soon Stolen Guido's time machine, have we? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] pysqlite for 2.5?
Bill Janssen [EMAIL PROTECTED] wrote: On the package naming issue: using em for email would be wrong, Eh, that should be import electronic_mail, then. And import simple_mail_transport_protocol_lib. just as db for database would be wrong. People who are familiar with Extensible Markup Language abbreviate it xml. People who are familiar with electronic mail abbreviate it email. And people who are familiar with the concept of a database abbreviate it db. Why are two right for the stdlib (sorry, standard library :), and the other wrong? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] pysqlite for 2.5?
Georg Brandl [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: db.sqlite3 ? +1 That would make sense if inclusion of more database-related modules was planned. Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as appropriate, and having a nice new namespace ready for them is a good idea. Whatever name is chosen: please no from sqlite3 import dbapi2 as sqlite! Amen. db.sqlite3 is the perfect name. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] What about PEP 299?
Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Georg Brandl [EMAIL PROTECTED] wrote: since I found myself writing if __name__ == '__main__' often these days, I wondered whether PEP 299 could be pronounced upon. I'm not proposing putting it into 2.5, but it should be relatively small a change. If you're asking for a quick pronouncement, it's going to be no. It's not worth the change (in docs, user habits, etc.) and there's nothing particularly broken. It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] What about PEP 299?
Guido van Rossum [EMAIL PROTECTED] wrote: On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote: It might be worth instead adding an option flag to the executable that implies from the loaded module, run __main__() with sys.argv as its argument(s), so the user can get this behaviour with `python -X somemodule.py`. You can do python -m somemodule as long as somemodule.py uses the if __name__=='__main__' convention. What does your proposal add? Well, it's not really my proposal. I'm just suggesting the behaviour in PEP299 could be added via a commandline option so that it doesn't introduce backward-incompatibility. I don't see any particular benefit to PEP299 myself -- I'd rather just add an entry to the style guide about standardizing the executable stanza and main() function. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] The path module PEP
Phillip J. Eby [EMAIL PROTECTED] wrote: I'd also note that using the / operator seems to me to be a big win on beautiful is better than ugly. It screams magic in a very un-Pythonic (and possibly very Perl-like) way. I'm not aware of any other part of the standard library grossly abusing standard operators in this way. As others have noted, / is being used here to mean precisely the opposite of what it means in every other use in Python, which alone should be justification for getting rid of it. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] The path module PEP
BJörn Lindqvist [EMAIL PROTECTED] wrote:
1. Make all python files in the a directory executable:
[...]
==
for f in Path('/usr/home/guido/bin'):
f.chmod(0755)
Iterating over a path string to read the contents of the directory possibly
pointed to by that string seems like magic implicit behaviour. Perhaps
making it a method explicitly returning an iterator would by more Pythonic?
for f in Path(...).readDir():
4. Splitting a path into directory and filename:
[...]
Path(/path/to/foo/bar.txt).splitpath()
Good. But the opposite isn't done similarly:
6. Create directory paths:
[...]
Path(foo) / bar / baz
Using / as path concatenation operator seems like un-Pythonic magic as
well (while + would be an improvement, it's still not a large one). I would
think
Path('foo').appendparts('bar', 'baz')
or similar would be more readable and obvious.
Charles
--
---
Charles Cazabon [EMAIL PROTECTED]
GPL'ed software available at: http://pyropus.ca/software/
---
___
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] timeout options in high-level networking modules
Steve Holden [EMAIL PROTECTED] wrote: Jim Fulton wrote: Yesterday, I needed to make a web request in a program (actually a test) that could block indefinately, so I needed to set a socket timeout. Unfortunately, AFAICT none of urllib, urllib2, httplib provide options to set the timeout on the sockets they use. I ended up having to roll my own code to make the request. [...] That's a very good idea. At present the only option one has is to set a global socket.defaulttimout() or somehow monkey-patch the modules you want to use, and neither of those options are entirely satisfactory. Basically any method that can create a new TCP connection should acquire an optional timeout=None parameter, right? Yes. It might also be nice if the modules that rely on blocking mode being set on sockets (basically anything using socket.ssl()) actually explicitly set that first. Right now, if you do socket.setdefaulttimeout() to a non-None value and then try to use anything that does SSL (poplib, imaplib), the connections will quickly die. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Plea to distribute debugging lib
David Abrahams [EMAIL PROTECTED] wrote: For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library. [...] Having to download the Python source and build the debug DLL was deemed unacceptable. I'm curious: why was this deemed unacceptable? Python's license is about as liberal as it gets, and the code is almost startlingly easy to compile -- easier than any other similarly-sized codebase I've had to work with. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Replacement for print in Python 3.0
Bill Janssen [EMAIL PROTECTED] wrote: And good riddance! The print statement harks back to ABC and even (unvisual) Basic. Out with it! I'm with Guido on this, BTW. After reviewing the PEP 3000 notes, I can find no justification there for removing print Well, how about the fact that basically all of Python's statements are for implementing logic (if, while, etc), controlling flow (return, yield, try, etc), and defining structure (def, class, etc). `print` stands pretty much alone as a statement which does none of these things -- in fact, it does nothing for the program but merely has the interesting side-effect of writing to stdout. It's an anomaly. It stands out in the language as a sore thumb waiting for Guido's hammer. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Replacement for print in Python 3.0
Bill Janssen [EMAIL PROTECTED] wrote:
I don't use print myself much, but for the occasional 3-line script.
But I think the user-friendliness of it is a good point, and makes up
for the weirdness of it all. There's something nice about being able
to write
print the answer is, 3*4+10
which is one of the reasons ABC and BASIC have it that way.
Providing you can live with adding a pair of parentheses to that, you can
have:
def print(*args):
sys.stdout.write(' '.join(args) + '\n')
I think the language would be cleaner if it lacked this weird exception for
`print`.
Charles
--
---
Charles Cazabon [EMAIL PROTECTED]
GPL'ed software available at: http://pyropus.ca/software/
---
___
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] Replacement for print in Python 3.0
Fredrik Lundh [EMAIL PROTECTED] wrote: Charles Cazabon wrote: in fact, it does nothing for the program but merely has the interesting side-effect of writing to stdout. yeah, real programmers don't generate output. That wasn't quite my point - I meant that the rest of Python's statements (to a one) all have a quite fundamental impact on what the code in question means. `print` doesn't. I write data filters in Python all the time -- but I virtually never use `print`. stdout.write() is more consistent /and/ parallel to stdin.read(). `print` should go away, at least as a statement. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Proof of the pudding: str.partition()
Michael Chermside [EMAIL PROTECTED] wrote: (*) An rpartition() function that searches from the right ...except that I understand why he included it and am convinced by the arguments (use cases can be demonstrated and people would expect it to be there and complain if it weren't). I would think that perhaps an optional second argument to the method that controls whether it searches from the start (default) or end of the string might be nicer than having two separate methods, even though that would lose parallelism with the current .find/.index. While I'm at it, why not propose that for py3k that .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split grow an optional fromright (or equivalent) optional keyword argument? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Proof of the pudding: str.partition()
Guido van Rossum [EMAIL PROTECTED] wrote: On 8/31/05, Charles Cazabon [EMAIL PROTECTED] wrote: While I'm at it, why not propose that for py3k that .rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split grow an optional fromright (or equivalent) optional keyword argument? This violates one of my design principles: Ah, excellent response. Are your design principles written down anywhere? I didn't see anything on your essays page about them, but I'd like to learn at the feet of the BDFL. don't add boolean options to an API that control the semantics in such a way that the option value is (nearly) always a constant. Instead, provide two different method names. Hmmm. I really dislike the additional names, but ... The motivation for this rule comes partly for performance: parameters are relatively expensive, and you shouldn't make the method test dynamically for a parameter value that is constant for the call site; I can see this. and partly from readability: don't bother the reader with having to remember the full general functionality and how it is affected by the various flags; This I don't think is so bad. It's analogous to providing the reverse parameter to sorted et al, and I don't think that's particularly hard to remember. It would also be rarely used; I use find/index tens of times more often than I use rfind/rindex, and I presume it would be the same for a hypothetical .part/.rpart. also, a Boolean positional argument is a really poor clue about its meaning, and it's easy to misremember the sense reversed. I totally agree. I therefore borrowed the time machine and modified my proposal to suggest it should be a keyword argument, not a positional one :). PS. This is a special case of a stronger design principle: don't let the *type* of the return value depend on the *value* of the arguments. Hmmm. In all of these cases, the type of the return value is constant. Only the value would change based on the value of the arguments. ... ? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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 design principles
Oren Tirosh [EMAIL PROTECTED] wrote: Not all proposed changes remove redundancy or add completely new things. Some of them just change the way certain things must be done. For example: * Moving compile, id, intern to sys * Replacing print with write/writeln And possibly the biggest change: * Reorganize the standard library to not be as shallow I'm between +0 and -1 on these. I don't find them enough of an improvement to break this common subset behavior. It's not quite the same as strict backward compatibility and I find it worthwhile to try to keep it. Writing programs that run on both 2.x and 3 may require ugly version-dependent tricks like: try: compile except NameError: from sys import compile Perhaps py3k could have a py2compat module. Importing it could have the effect of (for instance) putting compile, id, and intern into the global namespace, making print an alias for writeln, alias the standard library namespace, ... ? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] partition() (was: Remove str.find in 3.0?)
Jason Orendorff [EMAIL PROTECTED] wrote: Concerning names for partition(), I immediately thought of break(). Unfortunately it's taken. So, how about snap()? I like .part()/.rpart() (or failing that, .parts()/.rparts()). But if you really want something short that's similar in meaning, there's also .cut(). Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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: Migrating the Python CVS to Subversion
Guido van Rossum [EMAIL PROTECTED] wrote: I'm intrigued by Linus Torvald's preference for extremely distributed source control, but I have no experience and it seems a bit, um, experimental. git, which is Linus' home-grown replacement for BitKeeper, quickly attracted a development community and has grown into a reasonably full-featured distributed RCS. It is apparently already stable enough for serious use. If I was trying to pick an RCS for a large, distributed project, I would at least investigate it as a possibility. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Exception Reorg PEP checked in
Brett Cannon [EMAIL PROTECTED] wrote: On 8/4/05, Guido van Rossum [EMAIL PROTECTED] wrote: I just realized that keeping RuntimeError still does not resolve the issue that the name kind of sucks for realizing intrinsically that it is for quick-and-dirty exceptions (or am I the only one who thinks this?). Should we toss in a subclass called SimpleError? Much Python code I've looked at uses ValueError for this purpose. Would adding a special exception add much utility? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Wishlist: dowhile
Nicolas Fleury [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Why are you so excited about having until indented? You didn't give any examples with multiple occurrences. A single occurrence works just fine unindented, as PEP 315 has already shown. FWIW, I must say I disagree (about works just fine). I find PEP 315 counter-intuitive. There's multi-part blocks in Python, but they all behave like a step-sequence where you never come back to a previous step. What I mean is that after entering a finally/except/elif/else, there's no coming back in the try/if/for/while. My first impression when looking at: do: block1 while condition: block2 is that block1 is executed only once. Indeed. The original poster seems to want something that would work (not necessarily look) like this: do: block while condition with block executed once prior to condition first being tested. But the above is ugly, and you can get much the same effect with Python today: firsttime = True while firsttime or condition: block firsttime = False Seems fairly Pythonic to me. YMMV. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
