[Python-Dev] beta1 coming real soon
It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! I would really like it if someone on Windows could test the perf of patch http://python.org/sf/1479611 and see if it improves perf. I will test again on Mac ppc, Linux x86, and Linux amd64 to verify gains n ___ 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] 2.5 issues need resolving in a few days
The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. There is still the missing documentation for ctypes and element tree. I know there's been progress on ctypes. What are we going to do about ElementTree? Are we going to have another undocumented module in the core or should we pull ET out (that would also fix the xml issue)? Finally, there are the AST regressions. If there are patches that address any of these issues, respond with a link here. I'm guessing that all the possible features are not going to make it into 2.5. n ___ 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
Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). oops - I still had marked June 24 in my calendar! If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! I intend to merge in the current ctypes SF CVS, will try that today. Thomas ___ 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] Subversion repository question - back up to older versions
[EMAIL PROTECTED] wrote: I have three Python branches, trunk, release23-maint and release24-maint. In the (for example) release24-maint, what svn up command would I use to get to the 2.4.2 version? Tim First question: Timcd to the root of your release24-maint checkout, then Timsvn switch svn+ssh://[EMAIL PROTECTED]/python/tags/r242 How is that different than noting that r242 corresponds to revision 39619 and executing: svn up -r 39619 If you realize that each file/directory in Subversion is uniquely identified by a 2-space coordinate system [url, revision] (given a checkout, you can use svn info to get its coordinates), then we can say that svn up -r 39619 keeps the url changed and change the revision to whatever number you specified. In other words, you get the state of the working copy at whatever state it was that URL at that time. For instance, if you execute it within the trunk working copy, you will get the trunk at the moment 2.4.2 was released. On the other hand, svn switch moves the url: it basically moves your checkout from [whatever_url, whatever_rev] to [url_specified, HEAD], downloading the minimal set of diffs to do so. Given that /tags/r242 is a tag, it means that any revision is good, since nobody is going to commit into that directory (it will stay unchanged forever). So [/tags/r242, HEAD] is the same of any other [/tags/r242, REVNUM] (assuming of course that /tags/r242 was already created at the time of REVNUM). So basically you want svn switch to [/tags/r242, HEAD] if you don't plan on doing modifications, while you want [/branches/release24-maint, HEAD] if you want to work on the 2.4 branch. Going to [/branches/release24-maint, 39619] does not really serve many purposes: you have to find out and write 39619 manually, you still can't do commits since of course you want to work on the top of the branch, and you get less meaningful information if you later run svn info on the working copy (as you're probably going to forget what [/branches/release24-maint, 39619] means pretty soon, while [/tags/r242, NNN] is more clear). Giovanni Bajo ___ 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] UUID module
Quite a few people have expressed interest in having UUID functionality in the standard library, and previously on this list some suggested possibly using the uuid.py module i wrote: http://zesty.ca/python/uuid.py This module provides a UUID class, functions for generating version 1, 3, 4, and 5 UUIDs, and can convert UUIDs to and from strings of 32 hex digits and strings of 16 bytes. The thread of messages posted on python-dev begins here: http://mail.python.org/pipermail/python-dev/2006-March/062119.html My reading of this is that there was a pretty good consensus on the issues with this module that need to be addressed: (a) UUIDs should be immutable (and usable as dict keys). (b) The str() of a UUID should not contain curly braces. (c) The uuid1() function, which generates a version-1 UUID, uses a very slow method of getting the MAC address. (d) The retrieved MAC address should be cached. (e) Tests need to be written. The big question seems to be item (c); all the other items are easy to take care of. Assuming (a), (b), (d), and (e) are done, i see a few options for how to proceed from there: 1. Remove the uuid1() function, then put uuid.py in the standard library so at least we'll have the rest of the UUID functionality in 2.5b1. Fill in uuid1() later. 2. Remove the MAC-address functionality from uuid.py; instead let the caller give the MAC address as an argument to uuid1(). Put that in the standard library for 2.5b1 and fill in the function for retrieving the MAC address later. 3. Add uuid.py to the standard library with its current slow method of finding the MAC address (parsing the output of ifconfig or ipconfig), but cache the output so it's only slow the first time. 4. Figure out how to use ctypes to retrieve the MAC address. This would only work on certain platforms, but we could probably cover the major ones. On the other hand, it seems unlikely that this would be fully hammered out before the code freeze. 5. Don't include any UUID functionality in 2.5b1; put it off until 2.6. What are your thoughts on this? Thanks! -- ?!ng ___ 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] UUID module
Ka-Ping Yee wrote: Quite a few people have expressed interest in having UUID functionality in the standard library, and previously on this list some suggested possibly using the uuid.py module i wrote: http://zesty.ca/python/uuid.py +1! This module provides a UUID class, functions for generating version 1, 3, 4, and 5 UUIDs, and can convert UUIDs to and from strings of 32 hex digits and strings of 16 bytes. The thread of messages posted on python-dev begins here: http://mail.python.org/pipermail/python-dev/2006-March/062119.html My reading of this is that there was a pretty good consensus on the issues with this module that need to be addressed: (a) UUIDs should be immutable (and usable as dict keys). (b) The str() of a UUID should not contain curly braces. (c) The uuid1() function, which generates a version-1 UUID, uses a very slow method of getting the MAC address. (d) The retrieved MAC address should be cached. (e) Tests need to be written. (f) import uuid or import uuidlib ? The big question seems to be item (c); all the other items are easy to take care of. Assuming (a), (b), (d), and (e) are done, i see a few options for how to proceed from there: 1. Remove the uuid1() function, then put uuid.py in the standard library so at least we'll have the rest of the UUID functionality in 2.5b1. Fill in uuid1() later. 2. Remove the MAC-address functionality from uuid.py; instead let the caller give the MAC address as an argument to uuid1(). Put that in the standard library for 2.5b1 and fill in the function for retrieving the MAC address later. 3. Add uuid.py to the standard library with its current slow method of finding the MAC address (parsing the output of ifconfig or ipconfig), but cache the output so it's only slow the first time. 4. Figure out how to use ctypes to retrieve the MAC address. This would only work on certain platforms, but we could probably cover the major ones. On the other hand, it seems unlikely that this would be fully hammered out before the code freeze. 5. Don't include any UUID functionality in 2.5b1; put it off until 2.6. 6. Combine 2 and 3: require the user to pass in a MAC argument to uuid1, but provide a SlowGetMacAddress helper that wraps the existing code. /F ___ 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 Benchmarks
Fredrik Lundh wrote: M.-A. Lemburg wrote: The results were produced by pybench 2.0 and use time.time on Linux, plus a different calibration strategy. As a result these timings are a lot more repeatable than with pybench 1.3 and I've confirmed the timings using several runs to make sure. can you check in 2.0 ? (if it's not quite ready for public consumption, put it in the sandbox). I'll check it in once it's ready for prime-time, either later today or early next week. You can download a current snapshot from: http://www.egenix.com/files/python/pybench-2.0-2006-06-09.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 09 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2006-07-03: EuroPython 2006, CERN, Switzerland 23 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). [...] I would have liked to implement the last major missing piece from pysqlite - the authorizer hook - release pysqlite 2.3.0 and merge the changes into the Python core sqlite3 module. This would be an additional feature and not require any changes to the existing code. If you'd rather not have this merged because of new code, then I'll skip it. There are other changes I did in pysqlite for pysqlite 2.3.0 that I'd more strongly like to integrate here: http://initd.org/tracker/pysqlite/changeset/274 This changeset fixes a real bug that can lead to hard crashes and also makes the sqlite module more sane: - converter names are looked up in a case-insensitive manner (the old behaviour is confusing to users) - Errors in callbacks are not silently ignored any longer, but lead to the query being aborted - Additionaly, the error can be echoed to stderr if a debugging flag is set (default is off) -- Gerhard ___ 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] UUID module
Fredrik 6. Combine 2 and 3: require the user to pass in a MAC argument Fredrik to uuid1, but provide a SlowGetMacAddress helper that wraps Fredrik the existing code. Or make the MAC address an optional arg to uuid1. If given, use it. If not, use the slow lookup (then cache the result). Skip ___ 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 Benchmarks
M.-A. Lemburg wrote: You can download a current snapshot from: http://www.egenix.com/files/python/pybench-2.0-2006-06-09.zip believe it or not, but this hangs on my machine, under 2.5 trunk. and it hangs hard; nether control-c, break, or the task manager manages to kill it. if it's any clue, it prints --- PYBENCH 2.0 --- * using Python 2.5a2 * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.clock and that's it; the process is just sitting there, using exactly 0% CPU. /F ___ 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] UUID module
[EMAIL PROTECTED] wrote: Fredrik 6. Combine 2 and 3: require the user to pass in a MAC argument Fredrik to uuid1, but provide a SlowGetMacAddress helper that wraps Fredrik the existing code. Or make the MAC address an optional arg to uuid1. If given, use it. If not, use the slow lookup (then cache the result). the reason for making it a required argument is to make it clear that the code is using a suboptimal way to get at the MAC value. explicit is better than implicit etc etc. /F ___ 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] beta1 coming real soon
If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Is there any chance to fix mbcs bug? I think this is critical... My patch is here: http://python.org/sf/1455898 # Maybe, no one is using this codec? ___ 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 Benchmarks
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
You can download a current snapshot from:
http://www.egenix.com/files/python/pybench-2.0-2006-06-09.zip
believe it or not, but this hangs on my machine, under 2.5 trunk. and
it hangs hard; nether control-c, break, or the task manager manages to
kill it.
Weird.
if it's any clue, it prints
---
PYBENCH 2.0
---
* using Python 2.5a2
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.clock
and that's it; the process is just sitting there, using exactly 0% CPU.
This is the output to expect:
---
PYBENCH 2.0
---
* using Python 2.4.2
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time
Calibrating tests. Please wait...
Running 10 round(s) of the suite at warp factor 10:
* Round 1 done in 6.627 seconds.
* Round 2 done in 7.307 seconds.
* Round 3 done in 7.180 seconds.
...
Note that the calibration step takes a while.
Looking at the code, the only place where it could
hang (because it's relying on a few external tools)
is when fetching the platform details:
def get_machine_details():
import platform
buildno, builddate = platform.python_build()
python = platform.python_version()
if python '2.0':
try:
unichr(10)
except ValueError:
# UCS2 build (standard)
unicode = 'UCS2'
else:
# UCS4 build (most recent Linux distros)
unicode = 'UCS4'
else:
unicode = None
bits, linkage = platform.architecture()
return {
'platform': platform.platform(),
'processor': platform.processor(),
'executable': sys.executable,
'python': platform.python_version(),
'compiler': platform.python_compiler(),
'buildno': buildno,
'builddate': builddate,
'unicode': unicode,
'bits': bits,
}
It does run fine on my WinXP machine, both with the win32
package installed or not.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 09 2006)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2006-07-03: EuroPython 2006, CERN, Switzerland 23 days left
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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
H.Yamamoto wrote: If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Is there any chance to fix mbcs bug? I think this is critical... My patch is here: http://python.org/sf/1455898 The best way to throughly test the patch is of course to check it in. ;) I've tested the patch on Windows and there were no obvious bugs. Of course to *really* test the patch a Windows installation with a multibyte locale is required. # Maybe, no one is using this codec? The audience is indeed limited. Servus, Walter ___ 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] UUID module
Fredrik the reason for making it a required argument is to make it Fredrik clear that the code is using a suboptimal way to get at the Fredrik MAC value. Fredrik explicit is better than implicit etc etc. Can't we expect there will be a faster way to get at the MAC address at some point in the future, maybe via a _uuid extension module that does all the magic in C? Or is there something inherently slow in discovering a machine's MAC address (I realize such a task would probably be quite platform-depenedent). Skip ___ 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] Subversion repository question - back up to older versions
Giovanni If you realize that each file/directory in Subversion is Giovanni uniquely identified by a 2-space coordinate system [url, Giovanni revision] ... Thanks, I found this very helpful. I found it so helpful that I added a question to the dev faq with this as the answer. Hope you don't mind... It should show up on http://www.python.org/dev/faq/ as question 3.23 in a few minutes. Skip ___ 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.5 issues need resolving in a few days
On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On 6/9/06, Fredrik Lundh [EMAIL PROTECTED] wrote: 6.Combine 2 and 3: require the user to pass in a MAC argument to uuid1, but provide a SlowGetMacAddress helper that wraps the existing code.That sounds like the right thing to do, although I wouldn't call it slow; just let it be documented as 'might not always work and might be inefficient', so there's room to make it the perfect and preferred way to get a MAC address without having to rename it. (Not that I think that's a reliable prospect, but hey ;) -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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.5 issues need resolving in a few days
On Friday, June 09, 2006, at 03:34PM, Georg Brandl [EMAIL PROTECTED] wrote: Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Paul. It is, but it seems to disturb IDLE. That's no problem for me, but if someone is using IDLE, he should look into it. It doesn't disturb IDLE, but doesn't work in IDLE either. IDLE overrides the exit and quit builtins with different messages, hence IDLE users won't see the new behaviour. Ronald ___ 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
Thanks for the reminder. What I intend to add is to finalize the PCBuild8 directory, and fix CRT runtime error handling for VC8. The change as proposed involves adding macros around a select few CRT calls (fopen, strftime, etc) where user supplied parameters are passed to the CRT innards. Code would be added conditionally to errors.c and pyerrors.h, and macros defined in pyerrors.h. Any objections? Kristján -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neal Norwitz Sent: 9. júní 2006 06:24 To: Python Dev Subject: [Python-Dev] beta1 coming real soon It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! I would really like it if someone on Windows could test the perf of patch http://python.org/sf/1479611 and see if it improves perf. I will test again on Mac ppc, Linux x86, and Linux amd64 to verify gains n ___ 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/kristjan%40ccpgames.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] 2.5 issues need resolving in a few days
On 6/8/06, Neal Norwitz [EMAIL PROTECTED] wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. Really? The old situation is really evil, and the new approach is at least marginally better by giving users a way to migrate to a new non-evil approach. What exactly is the backwards incompatibility you speak of? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Fri, Jun 09, 2006, Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Okay, I guess I mis-remembered what had been agreed to. Should this go into What's New? This also disagrees with Misc/NEWS: - Patch #1446372: quit and exit can now be called from the interactive interpreter to exit. Here are my tests: : python Python 2.4 (#1, Jan 17 2005, 14:59:14) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2 Type help, copyright, credits or license for more information. quit 'Use Ctrl-D (i.e. EOF) to exit.' ./python Python 2.5a2 (trunk:46583, May 31 2006, 20:56:06) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2 Type help, copyright, credits or license for more information. quit Use quit() or Ctrl-D (i.e. EOF) to exit -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ 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] Subversion repository question - back up to older versions
[EMAIL PROTECTED] wrote: Giovanni If you realize that each file/directory in Subversion is Giovanni uniquely identified by a 2-space coordinate system [url, Giovanni revision] ... Thanks, I found this very helpful. I found it so helpful that I added a question to the dev faq with this as the answer. Hope you don't mind... It should show up on http://www.python.org/dev/faq/ as question 3.23 in a few minutes. Sure, I'm glad to help. You may want to revise it a little since it wasn't meant to be read out of the context... -- Giovanni Bajo ___ 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.5 issues need resolving in a few days
On 6/9/06, Aahz [EMAIL PROTECTED] wrote: On Fri, Jun 09, 2006, Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode.I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are...Okay, I guess I mis-remembered what had been agreed to.Should this go into What's New?This also disagrees with Misc/NEWS:- Patch #1446372: quit and exit can now be called from the interactiveinterpreter to exit.Here are my tests:: pythonPython 2.4 (#1, Jan 17 2005, 14:59:14) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2Type help, copyright, credits or license for more information. quit'Use Ctrl-D (i.e. EOF) to exit.' ./pythonPython 2.5a2 (trunk:46583, May 31 2006, 20:56:06)[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2Type help, copyright, credits or license for more information. quitUse quit() or Ctrl-D (i.e. EOF) to exitNote the magic word, called:centurion:~/python/python/trunk python2.4Python 2.4.4c0 (#2, Jun 8 2006, 01:12:27) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2Type help, copyright, credits or license for more information. quit()Traceback (most recent call last): File stdin, line 1, in ?TypeError: 'str' object is not callable centurion:~/python/python/trunk ./pythonPython 2.5a2 (trunk:46753, Jun 8 2006, 17:46:46) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2Type help, copyright, credits or license for more information. quit()centurion:~/python/python/trunk -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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.5 issues need resolving in a few days
On Fri, Jun 09, 2006 at 07:28:47AM -0700, Aahz wrote:
Okay, I guess I mis-remembered what had been agreed to. Should this go
into What's New?
Already there:
http://docs.python.org/dev/whatsnew/other-lang.html#SECTION000131.
(Fred, is it possible to set the anchors used for *sub*sections?
\label{} sets the filename used for sections, which is great, but
subsection URLs are still annoyingly long.)
--amk
___
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.5 issues need resolving in a few days
On Friday 09 June 2006 10:28, Guido van Rossum wrote: Really? The old situation is really evil, and the new approach is at least marginally better by giving users a way to migrate to a new non-evil approach. What exactly is the backwards incompatibility you speak of? The incompatibility depends on your point of view for this one. I don't think there is any for client code; you get the old behavior for the xml package, and predictable behavior for the xmlcore package. Martin's objection is that the sources for the xmlcore package can no longer be shared with the PyXML project. I understand that he wants to reduce the cost of maintaining two trees for what's essentially the same code. I played with some ideas for making the tree more agnostic to where it really lives, but wasn't particularly successful. When I was working on that, I found that the PyXML unit tests weren't passing. I didn't have time to pursue that, though. On the whole, I'm unconvinced that there's value in continuing to worry about being able to copy the source tree between the two projects at this time. There's almost no effort going into PyXML any more, as far as I can tell. In that light, the maintenance cost seems irrelevant compared to not finally solving the fundamental problem of magic in the xml package import. I must consider the problem a nice-to-solve issue rather than a particularly important issue. All the benefit is for PyXML, and shouldn't really impact Python releases. -Fred -- Fred L. Drake, Jr. fdrake at acm.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] Some more comments re new uriparse module, patch 1462525
On Thursday, Jun 8, 2006, Mike Brown writes: It appears that Paul uploaded a new version of his library on June 3: http://python.org/sf/1462525 I'm unclear on the relationship between the two now. Are they both up for consideration? That version was in response to comments from JJ Lee. Email also went to pydev (archived at http://mail.python.org/pipermail/python-dev/2006-June/065583.html) about it. One thing I forgot to mention in private email is that I'm concerned that the inclusion of URI reference resolution functionality has exceeded the scope of this 'urischemes' module that purports to be for 'extensible URI parsing'. It is becoming a scheme-aware and general-purpose syntactic processing library for URIs, and should be characterized as such in its name as well as in its documentation. ...which is why i called it 'uriparse'. Even without a new name and more accurately documented scope, people are going to see no reason not to add the rest of STD 66's functionality to it (percent-encoding, normalization for testing equivalence, syntax validation...). As you can see in Ft.Lib.Uri, the latter two are not at all hard to implement, especially if you use regular expressions. These all fall under syntactic operations on URIs, just like reference-resolution. Percent-encoding gets very hairy with its API details due to application-level uses that don't jive with STD 66 (e.g. the fuzzy specs and convoluted history governing application/x-www-form-urlencoded), the nuances of character encoding and Python string types, and widely varying expectations of users. ...all of which I consider scope creep. If someone else wants to add it, more power to them; I wrote this code to fix the deficiencies in the existing urlparse library, not to be an all-singing all-dancing STD 66 module. In fact, I don't care whether it's my code or someone else's that goes into the library - I just want something better than the existing urlparse library to go in, because the existing stuff has been acknowledged as insufficient. I've even provided working code with modifications to fix comments and criticism I've received. If you or someone else want to extend what I've done to add features or other functionality, that would be fine with me. If you want to rewrite the entire thing in a different vein (as Nick Coghlan as done), be my guest. I'm not married to my code or API or anything but getting an improved library into the stdlib. To that end, if it's decided to go with my code, I'll happily put in the work to bring it up to python community standards. Additional functionality will have to come from someone else though, as I'm not willing to try and scratch an itch I don't have - and I've already got a day job. --pj ___ 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.5 issues need resolving in a few days
I will be looking at the open AST issues today. Jeremy On 6/9/06, Neal Norwitz [EMAIL PROTECTED] wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. There is still the missing documentation for ctypes and element tree. I know there's been progress on ctypes. What are we going to do about ElementTree? Are we going to have another undocumented module in the core or should we pull ET out (that would also fix the xml issue)? Finally, there are the AST regressions. If there are patches that address any of these issues, respond with a link here. I'm guessing that all the possible features are not going to make it into 2.5. n ___ 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
Neal Norwitz [EMAIL PROTECTED] writes: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). I think it must be that way around, it's not like Anthony is sane now... Cheers, mwh -- Or can I sweep that can of worms under the rug? Please shove them under the garage. -- Greg Ward and Guido van Rossum mix their metaphors on python-dev ___ 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
Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! Would it be possible to move the schedule for beta 1 a few days? I'd like to merge ctypes CVS HEAD (with some fixes I still have to make) into Python SVN, but unfortunately sourceforge CVS is down again ;-(, and I'm running out of time. Thanks, Thomas ___ 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
Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! The other question is about feature freeze on external libraries. Is it strictly forbidden to add new features in ctypes during the (Python) beta period? Thomas ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Hello,
Recently I discovered that a small change to the Python grammar that
could help me a lot.
It's simply this: Currently, the expression x[] is a syntax error. I
suggest that it will be a valid syntax, and equivalent to x[()],
just as x[a, b] is equivalent to x[(a, b)] right now.
I discussed this in python-list, and Fredrik Lundh suggested that I
quickly write a pre-PEP if I want this to go into 2.5. Since I want
this, I wrote a pre-PEP.
It's available in the wiki, at
http://wiki.python.org/moin/EmptySubscriptListPEP and I also copied it
to this message.
I know that now is really close to 2.5b1, but I thought that perhaps
there was still a chance for this suggestion getting in, since:
* It's a simple change and there's almost nothing to be decided
except whether to accept it or not.
* It has a simple implementation (It was fairly easy for me to
implement it, and I know almost nothing about the AST).
* It causes no backwards compatibilities issues.
Ok, here's the pre-PEP. Please say what you think about it.
Have a good day,
Noam
PEP: XXX
Title: Allow Empty Subscript List Without Parentheses
Version: $Revision$
Last-Modified: $Date$
Author: Noam Raphael [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Jun-2006
Python-Version: 2.5?
Post-History: 30-Aug-2002
Abstract
This PEP suggests to allow the use of an empty subscript list, for
example ``x[]``, which is currently a syntax error. It is suggested
that in such a case, an empty tuple will be passed as an argument to
the __getitem__ and __setitem__ methods. This is consistent with the
current behaviour of passing a tuple with n elements to those methods
when a subscript list of length n is used, if it includes a comma.
Specification
=
The Python grammar specifies that inside the square brackets trailing
an expression, a list of subscripts, separated by commas, should be
given. If the list consists of a single subscript without a trailing
comma, a single object (an ellipsis, a slice or any other object) is
passed to the resulting __getitem__ or __setitem__ call. If the list
consists of many subscripts, or of a single subscript with a trailing
comma, a tuple is passed to the resulting __getitem__ or __setitem__
call, with an item for each subscript.
Here is the formal definition of the grammar:
::
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
subscriptlist: subscript (',' subscript)* [',']
subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
sliceop: ':' [test]
This PEP suggests to allow an empty subscript list, with nothing
inside the square brackets. It will result in passing an empty tuple
to the resulting __getitem__ or __setitem__ call.
The change in the grammar is to make subscriptlist in the first
quoted line optional:
::
trailer: '(' [arglist] ')' | '[' [subscriptlist] ']' | '.' NAME
Motivation
==
This suggestion allows you to refer to zero-dimensional arrays elegantly. In
NumPy, you can have arrays with a different number of dimensions. In
order to refer to a value in a two-dimensional array, you write
``a[i, j]``. In order to refer to a value in a one-dimensional array,
you write ``a[i]``. You can also have a zero-dimensional array, which
holds a single value (a scalar). To refer to its value, you currently
need to write ``a[()]``, which is unexpected - the user may not even
know that when he writes ``a[i, j]`` he constructs a tuple, so he
won't guess the ``a[()]`` syntax. If the suggestion is accepted, the
user will be able to write ``a[]`` in order to refer to the value, as
expected. It will even work without changing the NumPy package at all!
In the normal use of NumPy, you usually don't encounter
zero-dimensional arrays. However, the author of this PEP is designing
another library for managing multi-dimensional arrays of data. Its
purpose is similar to that of a spreadsheet - to analyze data and
preserve the relations between a source of a calculation and its
destination. In such an environment you may have many
multi-dimensional arrays - for example, the sales of several products
over several time periods. But you may also have several
zero-dimensional arrays, that is, single values - for example, the
income tax rate. It is desired that the access to the zero-dimensional
arrays will be consistent with the access to the multi-dimensional
arrays. Just using the name of the zero-dimensional array to obtain
its value isn't going to work - the array and the value it contains
have to be distinguished.
Rationale
=
Passing an empty tuple to the __getitem__ or __setitem__ call was
chosen because it is consistent with passing a tuple of n elements
when a subscript list of n elements is used. Also, it will make NumPy
and similar packages work as expected for zero-dimensional arrays
without
any changes.
Another hint for consistency: Currently, these equivalences hold:
::
x[i, j, k] -- x[(i, j, k)]
Re: [Python-Dev] [Web-SIG] wsgiref doc draft; reviews/patches wanted
At 02:56 PM 6/7/2006 -0400, Joe Gregorio wrote: Phillip, 1. It's not really clear from the abstract 'what' this library provides. You might want to consider moving the text from 1.1 up to the same level as the abstract. Done. 2. In section 1.1 you might want to consider dropping the sentence: Only authors of web servers and programming frameworks need to know every detail... It doesn't offer any concrete information and just indirectly makes WSGI look complicated. That bit was taken from AMK's draft; I'm going to trust his intuition here as to why he thought it was desirable to say this. 3. From the abstract: Having a standard interface makes it easy to use a WSGI-supporting application with a number of different web servers. is a little akward, how about: Having a standard interface makes it easy to use an application that supports WSGI with a number of different web servers. Done. 4. I believe the order of submodules presented is important and think that they should be listed with 'handlers' and 'simple_server' first: I agree that the order is important, but I intentionally chose the current order to be a gentle slope of complexity, from the near-trivial functions on up to the server/handler framework last. I'm not sure what ordering principle you're suggesting to use instead. 5. You might consider moving 'headers' into 'util'. Of course, you could go all the way in simplifying and move 'validate' in there too. Not and maintain backward compatibility. There is, after all, code in the field using these modules for about a year and a half now. ___ 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
On 9-jun-2006, at 8:23, Neal Norwitz wrote: It's June 9 in most parts of the world. The schedule calls for beta 1 on June 14. That means there's less than 4 days until the expected code freeze. Please don't rush to get everything in at the last minute. The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around). If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! I want to checkin patch 1491759 IDLE LF on MacOSX. This makes the IDLE interface more palatable on OSX, although it still doesn't look very good due to issues with AquaTk. Unless someone tells me not to I'll check this in this weekend. I also wouldn't mind if someone wants to review patch 1446489 zipfile: support for ZIP64. This add support for the ZIP64 extensions to zipfile which makes it possible to create huge zipfiles. I'm using this at work to manage zipfiles that are over 6GByte in size and contain over 50K files each. The patch includes documentation updates and new tests ;-) Ronald ___ 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
On 9-jun-2006, at 17:34, Thomas Heller wrote: The other question is about feature freeze on external libraries. Is it strictly forbidden to add new features in ctypes during the (Python) beta period? Now that you mention the feature freeze... The tools that generate the Carbon bindings on OSX (that is most of Mac/Modules) currently process the Universal Headers, which are basically the OS9 SDK. I'm contemplating modifying them to use the system headers instead, which would make it possible to update the Carbon bindings and support API features that were introduced in OSX. It is however rather unlikely that I'll manage to finish this before beta1 is out. How hard is the feature freeze? Would it be possible to update the Carbon bindings after beta1? Given Apple's focus on backward compatibility the update should only add new functionality, not remove existing functions/types. Ronald ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
This is an elaborate joke, right?
On 6/9/06, Noam Raphael [EMAIL PROTECTED] wrote:
Hello,
Recently I discovered that a small change to the Python grammar that
could help me a lot.
It's simply this: Currently, the expression x[] is a syntax error. I
suggest that it will be a valid syntax, and equivalent to x[()],
just as x[a, b] is equivalent to x[(a, b)] right now.
I discussed this in python-list, and Fredrik Lundh suggested that I
quickly write a pre-PEP if I want this to go into 2.5. Since I want
this, I wrote a pre-PEP.
It's available in the wiki, at
http://wiki.python.org/moin/EmptySubscriptListPEP and I also copied it
to this message.
I know that now is really close to 2.5b1, but I thought that perhaps
there was still a chance for this suggestion getting in, since:
* It's a simple change and there's almost nothing to be decided
except whether to accept it or not.
* It has a simple implementation (It was fairly easy for me to
implement it, and I know almost nothing about the AST).
* It causes no backwards compatibilities issues.
Ok, here's the pre-PEP. Please say what you think about it.
Have a good day,
Noam
PEP: XXX
Title: Allow Empty Subscript List Without Parentheses
Version: $Revision$
Last-Modified: $Date$
Author: Noam Raphael [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Jun-2006
Python-Version: 2.5?
Post-History: 30-Aug-2002
Abstract
This PEP suggests to allow the use of an empty subscript list, for
example ``x[]``, which is currently a syntax error. It is suggested
that in such a case, an empty tuple will be passed as an argument to
the __getitem__ and __setitem__ methods. This is consistent with the
current behaviour of passing a tuple with n elements to those methods
when a subscript list of length n is used, if it includes a comma.
Specification
=
The Python grammar specifies that inside the square brackets trailing
an expression, a list of subscripts, separated by commas, should be
given. If the list consists of a single subscript without a trailing
comma, a single object (an ellipsis, a slice or any other object) is
passed to the resulting __getitem__ or __setitem__ call. If the list
consists of many subscripts, or of a single subscript with a trailing
comma, a tuple is passed to the resulting __getitem__ or __setitem__
call, with an item for each subscript.
Here is the formal definition of the grammar:
::
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
subscriptlist: subscript (',' subscript)* [',']
subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
sliceop: ':' [test]
This PEP suggests to allow an empty subscript list, with nothing
inside the square brackets. It will result in passing an empty tuple
to the resulting __getitem__ or __setitem__ call.
The change in the grammar is to make subscriptlist in the first
quoted line optional:
::
trailer: '(' [arglist] ')' | '[' [subscriptlist] ']' | '.' NAME
Motivation
==
This suggestion allows you to refer to zero-dimensional arrays elegantly. In
NumPy, you can have arrays with a different number of dimensions. In
order to refer to a value in a two-dimensional array, you write
``a[i, j]``. In order to refer to a value in a one-dimensional array,
you write ``a[i]``. You can also have a zero-dimensional array, which
holds a single value (a scalar). To refer to its value, you currently
need to write ``a[()]``, which is unexpected - the user may not even
know that when he writes ``a[i, j]`` he constructs a tuple, so he
won't guess the ``a[()]`` syntax. If the suggestion is accepted, the
user will be able to write ``a[]`` in order to refer to the value, as
expected. It will even work without changing the NumPy package at all!
In the normal use of NumPy, you usually don't encounter
zero-dimensional arrays. However, the author of this PEP is designing
another library for managing multi-dimensional arrays of data. Its
purpose is similar to that of a spreadsheet - to analyze data and
preserve the relations between a source of a calculation and its
destination. In such an environment you may have many
multi-dimensional arrays - for example, the sales of several products
over several time periods. But you may also have several
zero-dimensional arrays, that is, single values - for example, the
income tax rate. It is desired that the access to the zero-dimensional
arrays will be consistent with the access to the multi-dimensional
arrays. Just using the name of the zero-dimensional array to obtain
its value isn't going to work - the array and the value it contains
have to be distinguished.
Rationale
=
Passing an empty tuple to the __getitem__ or __setitem__ call was
chosen because it is consistent with passing a tuple of n elements
when a subscript list of n elements is used. Also, it will make NumPy
and
[Python-Dev] FYI: wsgiref is now checked in
The checked-in code substantially matches the public 0.1 release of wsgiref. There are some minor changes to the docs and the test module, but these have also been made in the SVN trunk of wsgiref's home repository, so that future releases don't diverge too much. The plan is to continue to maintain the standalone version and update the stdlib from it as appropriate, although I don't know of anything that would be changing any time soon. The checkin includes a wsgiref.egg-info file, so if you have a program that uses setuptools to depend on wsgiref being installed, setuptools under Python 2.5 should detect that the stdlib already includes wsgiref. Thanks for all the feedback and assistance and code contributions. ___ 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
On 6/9/06, 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.That means there's less than 4 days until the expected code freeze.Please don't rush to get everything in at the last minute.The buildbots should remain green to keep Anthony happy and me sane (or is it the other way around).oops - I still had marked June 24 in my calendar!Do enough people use Google Calendar or a calendar app that support iCal feeds that it would be useful for someone to maintain a Gcal calendar that has the various Python dev related dates in it? -Brett If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message.Please get the bug fixes in ASAP.Remember to add tests!I intend to merge in the current ctypes SF CVS, will try that today.Thomas ___Python-Dev mailing listPython-Dev@python.orghttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.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] beta1 coming real soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 9 Jun 2006 09:54:29 -0700 Brett Cannon [EMAIL PROTECTED] wrote: Do enough people use Google Calendar or a calendar app that support iCal feeds that it would be useful for someone to maintain a Gcal calendar that has the various Python dev related dates in it? Great idea! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRImofnEjvBPtnXfVAQL61wP/XLobIymHE5WsVsS+6Rrcy3mHPgnPgjlR CYLLD0/71Qn5RXKTEvJ1ZWxLgzRSKeT2gzrp1T+bvcblksZcXBGYLXC2y5d0xo2W WLRnFLeVUmA0X+t573EmvOoA+4flwSy7sm26ui6nM1PTMo+/j+AfGOAkIoxTheFu 0SrPIJVpue4= =n7WJ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
On 6/9/06, Nicko van Someren [EMAIL PROTECTED] wrote: On 9 Jun 2006, at 17:44, Guido van Rossum wrote: This is an elaborate joke, right? On 6/9/06, Noam Raphael [EMAIL PROTECTED] wrote: ... It's simply this: Currently, the expression x[] is a syntax error. I suggest that it will be a valid syntax, and equivalent to x[()], just as x[a, b] is equivalent to x[(a, b)] right now. ... Motivation == This suggestion allows you to refer to zero-dimensional arrays elegantly. I don't think that this suggestion is any less reasonable the the very existence of zero-dimensional arrays in the first place, although in my personal opinion that's a fairly low bar. The language doesn't have zero-dimensional arrays, although it doesn't prevent users from defining them. but why would one want to index a zero-dimensional array, since it has no dimensions? It should be written as x, not x[]. The need for () is pretty clear and can be explained to beginners (zero-length arrays are not that unusual). The need for x[] is not clear to beginners, and accepting this as legal syntax just moves certain typos from compile-time to run-time detection. The timing is such that there's no way this can be added to 2.5 -- beta 1 is about to be released. It's true that new features can be added until that release -- but that's for features that have been agreed upon for a long time and just haven't gotten implemented yet -- not for brand new proposals. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Guido van Rossum wrote: On 6/9/06, Nicko van Someren [EMAIL PROTECTED] wrote: [...] The language doesn't have zero-dimensional arrays, although it doesn't prevent users from defining them. but why would one want to index a zero-dimensional array, since it has no dimensions? It should be written as x, not x[]. In Numpy, a 0-D array [for example, array(5)] is almost, but not quite, equivalent to scalar [for example, 5]. The difference is that the former is mutable. Thus a[()] = 3 will set the value of a 0-D array to 3 and a[()] will extract the current, scalar value of a, for instance if you need a hashable object. Whether that makes x[] desirable I won't venture an opinion. I don't see a lot of use of 0-D arrays in practice. [...] -tim ___ 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 wrote: If you plan to make a checkin adding a feature (even a simple one), you oughta let people know by responding to this message. Please get the bug fixes in ASAP. Remember to add tests! The other question is about feature freeze on external libraries. Is it strictly forbidden to add new features in ctypes during the (Python) beta period? I think it strictly requires explicit permission of the release manager. If many people want more time, we should move the release schedule. OTOH, there will always be Python 2.6. Regards, Martin ___ 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
Ronald Oussoren wrote: How hard is the feature freeze? Would it be possible to update the Carbon bindings after beta1? Given Apple's focus on backward compatibility the update should only add new functionality, not remove existing functions/types. I'd say it's absolute wrt. to requiring permission from the release manager. The point of not allowing new features after a beta release is that one wants to avoid getting untested new features into a release. For that goal, it is not that relevant whether the new features are guaranteed not to break any existing features - they still don't get the testing that the beta releases try to achieve. Regards, Martin ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Noam Raphael wrote: This PEP suggests to allow the use of an empty subscript list, for example ``x[]``, which is currently a syntax error. It is suggested that in such a case, an empty tuple will be passed as an argument to the __getitem__ and __setitem__ methods. This is consistent with the current behaviour of passing a tuple with n elements to those methods when a subscript list of length n is used, if it includes a comma. It's not, really -- unless other places where a tuple can appear were changed likewise, e.g. x = would have to assign an empty tuple to x, etc. But you may also have several zero-dimensional arrays, that is, single values - for example, the income tax rate. But *why* do these need to be 0-dimensional arrays rather than just scalars? I'm having trouble seeing any use for such a distinction. I'm particularly unconvinced by the spreadsheet argument. In that context, I'd say that everything is a 2-D array, and a single cell is a 1x1 2-D array, not a 0-D array. -- Greg ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Alex Martelli wrote: Well, x=23 on one side, and x[]=23 aka x[()]=23 on the other, have drastically different semantics. Indexing refers to the contents of the zero-dimensional container, rather than to a name to which the container happens to be bound (but isn't any more, once one assigns to that name rather than to an indexing thereof). It's not clear to me that a 0-D array should be regarded as a container holding a single item, rather than just an item on its own. Think about how you get from an N dimensional array to an N-1 dimensional array: you index it, e.g. A2 = [[1, 2], [3, 4]] # a 2D array A1 = A2[1] # a 1D array A0 = A1[1] # a 0D array??? print A0 What do you think this will print? -- Greg ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Tim Hochberg wrote: In Numpy, a 0-D array [for example, array(5)] is almost, but not quite, equivalent to scalar [for example, 5]. The difference is that the former is mutable. Hmmm, I hadn't considered that. I suppose this is something that arises from NumPy's view semantics of indexing and slicing. Whether that makes x[] desirable I won't venture an opinion. I don't see a lot of use of 0-D arrays in practice. Actually, I *have* just thought of a use for it: def outer(): x = array(0) def inner(): x[] = 42 Bingo - write access to outer scopes! Okay, I'm +0 on this now. But for that use, we'd need a more convenient way of creating one than importing NumPy and using array(). -- Greg ___ 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] -Wi working for anyone else?
I discovered last night that if you run ``./python.exe -Wi`` the interpreter exists rather badly:: Fatal Python error: PyThreadState_Get: no current threadAnyone else seeing this error on any other platforms or have an inkling of what checkin would cause this? -Brett ___ 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] -Wi working for anyone else?
[Brett Cannon] I discovered last night that if you run ``./python.exe -Wi`` the interpreter exists rather badly:: Fatal Python error: PyThreadState_Get: no current thread Anyone else seeing this error on any other platforms or have an inkling of what checkin would cause this? See comments on the bug report report you opened: http://www.python.org/sf/1503294 ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Greg Ewing wrote: Tim Hochberg wrote: In Numpy, a 0-D array [for example, array(5)] is almost, but not quite, equivalent to scalar [for example, 5]. The difference is that the former is mutable. Hmmm, I hadn't considered that. I suppose this is something that arises from NumPy's view semantics of indexing and slicing. I think it more comes from the n-dimensional array approach - 'n=0' is then a natural issue to consider. The Python core doesn't really get into that space, because it only really considers 1-dimensional sequences. Whether that makes x[] desirable I won't venture an opinion. I don't see a lot of use of 0-D arrays in practice. Actually, I *have* just thought of a use for it: def outer(): x = array(0) def inner(): x[] = 42 Bingo - write access to outer scopes! Okay, I'm +0 on this now. But for that use, we'd need a more convenient way of creating one than importing NumPy and using array(). Another 'initially -1, but +0 after reading the PEP thread' here. Also, with Travis's proposed dimarray type hopefully arriving in time for Python 2.6, I'd expect for this to be as simple as doing 'from array import dimarray' at the top of the module, and then: def outer(): x = dimarray(0) def inner(): x[] = 42 My personal hopes for the dimarray type are that it will have an internal data representation that's compatible with numpy, but Python-level semantics that are closer to those of the rest of the Python core (such as providing copy-on-slice behaviour instead of numpy's view-on-slice). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Pre-PEP: Allow Empty Subscript List Without Parentheses
Alex Martelli wrote:
On Jun 9, 2006, at 4:55 PM, Greg Ewing wrote:
...
Think about how you get from an N dimensional array to
an N-1 dimensional array: you index it, e.g.
A2 = [[1, 2], [3, 4]] # a 2D array
A1 = A2[1] # a 1D array
A0 = A1[1] # a 0D array???
print A0
What do you think this will print?
Don't confuse arrays with lists...:
A2 = Numeric.array([[1, 2], [3, 4]], Numeric.Float32)
A1 = A2[1]
A0 = A1[1]
type(A0)
type 'array'
It doesn't work the same if you specify Numeric.Float64 instead -- an
ancient wart of Numeric, of course. Still, Numeric and its
descendants are the way in Python to get multi-dimensional arrays,
since the stdlib's array module only supports one-dimensional ones,
and lists are not arrays.
Note that this wart has been pretty much killed in numpy by supplying a
full complement of scalar types:
import numpy
A2 = numpy.array([[1,2], [3,4]], numpy.float32)
A1 = A2[1]
A0 = A1[1]
A0
4.0
type(A0)
type 'float32scalar'
The same excercise with float64 will give you a float64 scalar. The
behaviour in this area is overall much more consistent now. You can
still get a 0-D array by doing array(4.0) and possibly a few other ways,
but there much less common. These scalar objects are immutable, but have
all (or at least most) of the the array methods and attributes. For example:
A0.dtype
dtype('f4')
dtype is more or less equivalent to Numeric's typecode().
-tim
___
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
- Original Message - From: Walter Dörwald [EMAIL PROTECTED] To: H.Yamamoto [EMAIL PROTECTED] Cc: python-dev python-dev@python.org Sent: Friday, June 09, 2006 7:56 PM Subject: Re: [Python-Dev] beta1 coming real soon The best way to throughly test the patch is of course to check it in. ;) Is it too risky? ;) I've tested the patch on Windows and there were no obvious bugs. Of course to *really* test the patch a Windows installation with a multibyte locale is required. # Maybe, no one is using this codec? The audience is indeed limited. Yes, I agree. And the audience who has 64bit Windows with multibyte locale should be much more limitted... ___ 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
