[Python-Dev] RELEASED Python 2.4.2, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.2 (release candidate 1). Python 2.4.2 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 60 bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.4.2 will follow in about a week's time. For more information on Python 2.4.2, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.2 Highlights of this new release include: - Bug fixes. According to the release notes, more than 60 have been fixed, including bugs that prevented Python from working properly on 64 bit HP/UX and AIX systems. Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy the new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
Ronald Oussoren wrote: > > On 22-sep-2005, at 5:26, Guido van Rossum wrote: > >> The platform module has a way to map system names such as returned by >> uname() to marketing names. It maps SunOS to Solaris, for example. But >> it doesn't map Darwin to Mac OS X. I think I know how to map Darwin >> version numbers to OS X version numbers: from >> http://www.opensource.apple.com/darwinsource/ it is clear that OS X >> 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= >> 10.1. I'd be happy to write the code and add it to system_alias() in >> platform.py. Is this a good idea? > > > There's no good reason to assume that the mapping from kernel version > to marketing version will stay the same in the future. The savest way > to get the marketing version of the currently running OSX is to run / > usr/sbin/sw_vers and parse its output. There might also be a public API > for getting the same information. Py2app, and specifically the > bdist_mpkg component of that, contains code to parse sw_vers output. I don't have access to Macs, so there nothing much I can say about this. In general, it's always better to rely on system tools for finding the marketing name of an OS than to try to come up with a work-around. If gestalt() returns the proper name, then this should be used. If sw_vers provides a more reliable way to do this, parsing its output seems like a better idea. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 22 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Anthony Baxter wrote: > Starting in about 11 hours time, the release24-maint branch is FROZEN > for the 2.4.2c1 release. The freeze will last for around a day, and > then we're in a state of mostly-frozen for another week, until 2.4.2 > (final). During that week, please don't check things into the branch > unless you check with me first. Let's make this a nice painless > release. > > I'll send another message once 2.4.2 is done. Do you think the patch at https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 could go in before 2.4.2 final? It's a rather major issue within cStringIO.writelines(). Reinhold -- Mail address is perfectly valid! ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes: > Anthony Baxter wrote: >> Starting in about 11 hours time, the release24-maint branch is FROZEN >> for the 2.4.2c1 release. The freeze will last for around a day, and >> then we're in a state of mostly-frozen for another week, until 2.4.2 >> (final). During that week, please don't check things into the branch >> unless you check with me first. Let's make this a nice painless >> release. >> >> I'll send another message once 2.4.2 is done. > > Do you think the patch at > > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 > > could go in before 2.4.2 final? It's a rather major issue > within cStringIO.writelines(). Oh, I was looking at that one too :) I was going to check it in after building and testing finished... Cheers, mwh -- The gripping hand is really that there are morons everywhere, it's just that the Americon morons are funnier than average. -- Pim van Riezen, alt.sysadmin.recovery ___ 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] GIL, Python 3, and MP vs. UP
Hi, > On *nix, use a unix domain socket (location in the filesystem which acts > as a listening socket). On Windows, you can use cTypes, pywin32, etc., > to create a global mutex and/or COM interface. Ok, but for a very simple and crude need like mine (the application code using this IPC means is not more than 20 lines long, and it has no performance requirement), it would be useful to have an abstraction in the standard library. Regards Antoine. ___ 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] "and" and "or" operators in Py3.0
> In C, C++, C#, Java, and JavaScript, what do you get when you print the > result of 3 || 10? In C and C++, you get 1. (in c++ the result is actually true, not 1, but true prints as 1 by default for backward compatibility) ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Can the fix for [ 1163563 ] Sub threads execute in restricted mode (http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5470&atid=105470 ) go in before 2.4.2 final? This is a real show stopper for us - we can't move to 2.4 without it. Cheers, Max On 9/22/05, Michael Hudson <[EMAIL PROTECTED]> wrote: Reinhold Birkenfeld <[EMAIL PROTECTED] > writes:> Anthony Baxter wrote:>> Starting in about 11 hours time, the release24-maint branch is FROZEN>> for the 2.4.2c1 release. The freeze will last for around a day, and>> then we're in a state of mostly-frozen for another week, until 2.4.2>> (final). During that week, please don't check things into the branch>> unless you check with me first. Let's make this a nice painless>> release. I'll send another message once 2.4.2 is done.>> Do you think the patch at>> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 >> could go in before 2.4.2 final? It's a rather major issue> within cStringIO.writelines().Oh, I was looking at that one too :) I was going to check it in afterbuilding and testing finished... Cheers,mwh--The gripping hand is really that there are morons everywhere, it'sjust that the Americon morons are funnier than average. -- Pim van Riezen, alt.sysadmin.recovery ___Python-Dev mailing listPython-Dev@python.orghttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anothermax%40gmail.com -- flickr: http://www.flickr.com/photos/anothermax/sets ___ 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] bool(iter([])) changed between 2.3 and 2.4
Greg Ewing wrote:
> But if the docs don't mention anything about true or
> false values for some particular type, one tends to
> assume that all values are true, as is the default
> for user-defined classes.
The tutorials and such stress that python doesn't
typically care about a specific "True" or "False"; the
normal distinction is between "empty" and "not empty".
0, None, (), [], {} all come out as false.
"Is there anything left?" is a pretty analogy for iterators,
particularly since the examples tend to start with list
or file iterators.
x = [] or iter([]) or "nope" does just what *I* expect.
If you want to change it back, so be it, but it will break
code that way too; please at least make big notes in
the documentation.
-jJ
___
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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
On Thursday 22 September 2005 23:36, Jeremy Maxfield wrote: > Can the fix for [ 1163563 ] Sub threads execute in restricted mode > ( > http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&gr >oup_id=5470&atid=105470 ) > go in before 2.4.2 final? > This is a real show stopper for us - we can't move to 2.4 without > it. Cheers, > Max I'm not sure - mwh, how risky a patch is this? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] IMPORTANT: release24-maint branch is THAWED (partly frozen ; )
So the 2.4.2c1 release seems to be not a brown-paper-bag release. The branch should be considered ok for those critical fixes that need to go in before 2.4.2 final - please, please, if you're not absolutely sure, ask me first. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Visibility scope for "for/while/if" statements
Hello, Don't want to be importunate annoyingly asking the things probably trivial for experienced community, but need to ask it anyway, after spending about two hours trying to find well-camouflaged error caused by it. Why the variables defined inside "for"/"while"/"if" statements (including loop variables for "for") are visible outside this scope? This litters the namespace, makes things more complex and requires even more attention from the programmer than even the uneasy C. Or makes him to watch for using each variable only once (prohibiting from using usual i/j/k variables); otherwise copypasting a piece of code can cause hardly-findable errors. But not even the variables from inside of statements are forgot in the outside namespace; what is most ridiculous is that the inner variables from a list comprehension are kept outside the comprehension! Yes, I am aware of one use case for this... er, feature. It could be useful to remember the last item of the loop after the loop is done... sometimes. But what is it for in other cases, except confusing the programmer? Or maybe can someone hint me whether I can somehow switch the behaviour on source-level to avoid keeping the variables outside the statements? Something like Perlish "import strict"? I couldn't find it myself. While global change of Python to the variables local to statements and list comprehension could definitely affect too much programs, adding it on a per-source level would keep the compatibility while making the life of Python programmers safer. Thanks in advance. Appendix 1: examples. cut here #!/usr/bin/env python -t a1 = ['a', 'b', 'c', 'd', 'e'] # Loop variable is alive outside the loop for k in a1: pass print "k: %s" % k # Loop variable is alive even outside the list comprehension! b1 = [l for l in a1] print "l: %s" % l # If there are several loops in a comprehension, # variables from all of them are kept intact c1 = [(m, n) for m in a1 for n in b1] print "m: %s, n: %s" % (m, n) # Loop variable is kept even from nested comprehensions d1 = [o for o in [p for p in a1]] print "o: %s, p: %s" % (o, p) # And the winner is... for r in a1: print "r0: %s, " % r, e1 = [r for r in b1] # Now try to access the "r" variable from the loop! print "r1: %s" % r cut here -- With best regards, Alexander mailto:[EMAIL PROTECTED] ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Anthony Baxter <[EMAIL PROTECTED]> writes: > On Thursday 22 September 2005 23:36, Jeremy Maxfield wrote: >> Can the fix for [ 1163563 ] Sub threads execute in restricted mode >> ( >> http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&gr >>oup_id=5470&atid=105470 ) >> go in before 2.4.2 final? >> This is a real show stopper for us - we can't move to 2.4 without >> it. Cheers, >> Max > > I'm not sure - mwh, how risky a patch is this? Well, unless I'm much mistaken it's in 2.4.2c1 Cheers, mwh -- I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting the almighty.-- /will on the doc-sig ___ 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
I don't think it's too risky. Michael Hudson did the work and it's been checked into the python CVS for a while. (Python/pystate.c Rev 2.42 and Modules/threadmodule.c Rev 2.64 are required files). We're stuck on Python 2.3.3 because of this bug...(2.4 thread code with this bug was backported to 2.3.5). Max On 9/22/05, Anthony Baxter <[EMAIL PROTECTED]> wrote: On Thursday 22 September 2005 23:36, Jeremy Maxfield wrote:> Can the fix for [ 1163563 ] Sub threads execute in restricted mode > (> http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&gr>oup_id=5470&atid=105470 ) > go in before 2.4.2 final?> This is a real show stopper for us - we can't move to 2.4 without> it. Cheers,> MaxI'm not sure - mwh, how risky a patch is this?Anthony--Anthony Baxter < [EMAIL PROTECTED]>It's never too late to have a happy childhood.-- flickr: http://www.flickr.com/photos/anothermax/sets ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a conditional expression in Py3.0
> My problem with this syntax is that it can be hard to read: > > return if self.arg is None then default else self.arg > > looks worryingly like > > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > > to me. Interesting. What about return if self.arg is None: default else: self.arg ? ___ 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] unintentional and unsafe use of realpath()
Filed:
https://sourceforge.net/tracker/index.php?func=detail&aid=1298813&group_id=5470&atid=305470
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046
Misa
On Wed, Sep 21, 2005 at 12:04:03PM -0400, Peter Jones wrote:
> On Wed, 2005-09-14 at 15:25 -0400, Peter Jones wrote:
> [ comments and a patch for sysmodule.c and some configure related files]
>
> ... and that patch has obvious problems as well.
>
> Here's a corrected one:
>
> --- Python-2.4.1/pyconfig.h.in.canonicalize 2005-09-14 11:47:04.0
> -0400
> +++ Python-2.4.1/pyconfig.h.in2005-09-14 11:47:02.0 -0400
> @@ -58,6 +58,9 @@
> /* Define if pthread_sigmask() does not work on your system. */
> #undef HAVE_BROKEN_PTHREAD_SIGMASK
>
> +/* Define to 1 if you have the `canonicalize_file_name' function. */
> +#undef HAVE_CANONICALIZE_FILE_NAME
> +
> /* Define to 1 if you have the `chown' function. */
> #undef HAVE_CHOWN
>
> --- Python-2.4.1/Python/sysmodule.c.canonicalize 2005-09-14
> 11:53:30.0 -0400
> +++ Python-2.4.1/Python/sysmodule.c 2005-09-14 11:52:04.0 -0400
> @@ -1184,6 +1184,11 @@
> char *p = NULL;
> int n = 0;
> PyObject *a;
> +#ifdef HAVE_CANONICALIZE_FILE_NAME
> + argv0 = canonicalize_file_name(argv0);
> + if (argv0 == NULL)
> + Py_FatalError("no mem for sys.argv");
> +#else /* ! HAVE_CANONICALIZE_FILE_NAME */
> #ifdef HAVE_READLINK
> char link[MAXPATHLEN+1];
> char argv0copy[2*MAXPATHLEN+1];
> @@ -1256,9 +1261,13 @@
> #endif /* Unix */
> }
> #endif /* All others */
> +#endif /* ! HAVE_CANONICALIZE_FILE_NAME */
> a = PyString_FromStringAndSize(argv0, n);
> if (a == NULL)
> Py_FatalError("no mem for sys.path insertion");
> +#ifdef HAVE_CANONICALIZE_FILE_NAME
> + free(argv0);
> +#endif /* HAVE_CANONICALIZE_FILE_NAME */
> if (PyList_Insert(path, 0, a) < 0)
> Py_FatalError("sys.path.insert(0) failed");
> Py_DECREF(a);
> --- Python-2.4.1/configure.in.canonicalize2005-09-14 11:46:00.0
> -0400
> +++ Python-2.4.1/configure.in 2005-09-14 11:47:22.0 -0400
> @@ -2096,8 +2096,8 @@
> AC_MSG_RESULT(MACHDEP_OBJS)
>
> # checks for library functions
> -AC_CHECK_FUNCS(alarm bind_textdomain_codeset chown clock confstr ctermid \
> - execv fork fpathconf ftime ftruncate \
> +AC_CHECK_FUNCS(alarm bind_textdomain_codeset canonicalize_file_name chown \
> + clock confstr ctermid execv fork fpathconf ftime ftruncate \
> gai_strerror getgroups getlogin getloadavg getpeername getpgid getpid \
> getpriority getpwent getsid getwd \
> kill killpg lchown lstat mkfifo mknod mktime \
>
> --
> Peter
>
> ___
> 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/misa%40redhat.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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Sorry I think you're 'much mistaken'... The revision of PyState.c in the rc242c1 looks like 2.38.22 (should be 2.42) and threadmodule.c looks like 2.59 (should be 2.64) Cheers, Max On 9/22/05, Michael Hudson <[EMAIL PROTECTED]> wrote: Anthony Baxter <[EMAIL PROTECTED]> writes: > On Thursday 22 September 2005 23:36, Jeremy Maxfield wrote:>> Can the fix for [ 1163563 ] Sub threads execute in restricted mode>> (>> http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&gr>>oup_id=5470&atid=105470 )>> go in before 2.4.2 final?>> This is a real show stopper for us - we can't move to 2.4 without>> it. Cheers,>> Max>> I'm not sure - mwh, how risky a patch is this?Well, unless I'm much mistaken it's in 2.4.2c1Cheers,mwh--I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting thealmighty.-- /will on the doc-sig___Python-Dev mailing list Python-Dev@python.orghttp://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/anothermax%40gmail.com-- flickr: http://www.flickr.com/photos/anothermax/sets ___ 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] bool(iter([])) changed between 2.3 and 2.4
On 9/22/05, Jim Jewett <[EMAIL PROTECTED]> wrote: > "Is there anything left?" is a pretty analogy for iterators, But unmaintainable for iterators in general. This was considered ad nauseam when iterators were initially introduced, and it was an explicit decision *not* to provide an API to look ahead. We should *not* give people a way to start coding like this: while it: x = it.next() ...process x... when they should be writing this instead: for x in it: ...process x... How would you implement the "is there anything left" functionality if the iterator is in fact a generator? (I know, the answer is buffering. But that has problems too. It was all considered when we designed it.) -- --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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
Thanks all! I won't touch it. /usr/bin/sw_vers is the way to go. On 9/22/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Ronald Oussoren wrote: > > > > On 22-sep-2005, at 5:26, Guido van Rossum wrote: > > > >> The platform module has a way to map system names such as returned by > >> uname() to marketing names. It maps SunOS to Solaris, for example. But > >> it doesn't map Darwin to Mac OS X. I think I know how to map Darwin > >> version numbers to OS X version numbers: from > >> http://www.opensource.apple.com/darwinsource/ it is clear that OS X > >> 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= > >> 10.1. I'd be happy to write the code and add it to system_alias() in > >> platform.py. Is this a good idea? > > > > > > There's no good reason to assume that the mapping from kernel version > > to marketing version will stay the same in the future. The savest way > > to get the marketing version of the currently running OSX is to run / > > usr/sbin/sw_vers and parse its output. There might also be a public API > > for getting the same information. Py2app, and specifically the > > bdist_mpkg component of that, contains code to parse sw_vers output. > > I don't have access to Macs, so there nothing much I can say > about this. > > In general, it's always better to rely on system tools for > finding the marketing name of an OS than to try to come > up with a work-around. If gestalt() returns the proper name, > then this should be used. If sw_vers provides a more reliable > way to do this, parsing its output seems like a better idea. -- --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] Visibility scope for "for/while/if" statements
Alexander Myodov <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Don't want to be importunate annoyingly asking the things probably
> trivial for experienced community, but need to ask it anyway, after
> spending about two hours trying to find well-camouflaged error caused
> by it.
In the future you should test your assumptions before writing software
with them.
> Why the variables defined inside "for"/"while"/"if" statements
> (including loop variables for "for") are visible outside this scope?
if and while statements don't define variables, so they can't expose
them later in the scope.
In regards to 'for' loops, they have always done that, there is code
that relies on that behavior, and changing behavior would unnecessarily
break code.
As for list comprehensions, they were literally meant to be a
completely equivalent translation of a set of for loops. That is:
x = []
for i in foo:
if f(i):
x.append(i)
could be translated into
x = [i for i in foo if f(i)]
and one would get the exact same side effects, including the 'leaking'
of the most recently bound i into the local scope. The leakage was not
accidental.
> Yes, I am aware of one use case for this... er, feature.
> It could be useful to remember the last item of the loop after the loop
> is done... sometimes. But what is it for in other cases, except
> confusing the programmer?
There is a great reason: there generally exists two namespaces in Python,
locals and globals (you can get a representation of of locals by using
locals() (your changes to the dictionary won't change the local scope),
and get a reference to the globals dictionary by globals()...there is
also __builtins__, but you shouldn't be playing with that unless you
know what you are doing). These namespaces offer you access to other
namespaces (class, module, etc.).
In most cases (the body of a function or method), the local scope is
defined as an array with offset lookups:
>>> def foo(n):
... n + 1
...
>>> dis.dis(foo)
2 0 LOAD_FAST0 (n) <- look at this opcode
3 LOAD_CONST 1 (1)
6 BINARY_ADD
7 POP_TOP
8 LOAD_CONST 0 (None)
11 RETURN_VALUE
>>>
This results in the bytecode to be executed being significantly faster
than if it were to reference a dictionary (like globals).
>>> dis.dis(compile('n+1', '_', 'single'))
1 0 LOAD_NAME0 (n) <- compare with this
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 PRINT_EXPR
8 LOAD_CONST 1 (None)
11 RETURN_VALUE
Since the LOAD_NAME opcode does a dictionary lookup, it is necessarily
slower than an array + offset lookup.
Further, you should clarify what you would want this mythical non-leaky
for loop to do in various cases. What would happen in the following
case?
i = None
for i in ...:
...
print i
... assuming that the loop executed more than once? Would you always
get 'None' printed, or would you get the content of the last variable?
What about:
x = None
for i in ...:
x = f(i)
...
print x
Would 'x' be kept after the loop finished executing?
I would imagine in your current code you are running something like
this:
i = #some important value
... #many lines of code
for i in ...:
...
#you access the 'i' you bound a long time ago
In this case, you are making a common new programmer mistake by using
the same variable name for two disparate concepts. If the 'i' that was
initially bound was important through the lifetime of the scope, you
should have named it differently than the 'i' that was merely a loop
variable.
I will also point out that in general, not leaking/exposing/etc. such
variables would necessarily slow down Python. Why? Because it would
necessitate nesting the concept of pseudo-namespaces. Now, when a
function is compiled, nearly every local name is known, and they can be
made fast (in the Python sense). If one were to nest pseudo namespaces,
one would necessarily have another namespace lookup for every nested for
loop. More specifically, accessing 'foo' in these three different
nestings would take different amounts of time.
for i in xrange(10):
x = foo
for i in xrange(10):
for j in xrange(10):
x = foo
for i in xrange(10):
for j in xrange(10):
for k in xrange(10):
x = foo
And in the case that you do or don't want 'x' to 'leak' into the
surrounding scope, you either take the speed hit again, or break quite a
bit of code and be inconsistant.
> Or maybe can someone hint me whether I can somehow switch the behaviour on
> source-level to avoid keeping the variables outside the statements?
No.
> Something like Perlish "import strict"? I couldn't find it myself.
> While global change of Python to the variables local to sta
Re: [Python-Dev] Adding a conditional expression in Py3.0
"Andrew Koenig" <[EMAIL PROTECTED]> wrote: > > > > My problem with this syntax is that it can be hard to read: > > > > return if self.arg is None then default else self.arg > > > > looks worryingly like > > > > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > > > > to me. > > Interesting. What about > > return if self.arg is None: default else: self.arg That's awful. It would confuse everyone as to why LCs and GEs don't have punctuation while these do. In that sense, I am not convinced that it should have keywords AND punctuation, one or the other. - Josiah ___ 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
/usr/bin/sw_vers technically calls a private (at least undocumented)
CoreFoundation API, it doesn't parse that plist directly :)
On further inspection, it looks like parsing the plist directly is
supported API these days (see the bottom of ):
import plistlib
dct = plistlib.Plist.fromFile('/System/Library/CoreServices/
SystemVersion.plist')
print '%(ProductName)s %(ProductVersion)s' % dct
-bob
On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
> "rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on
> anything we ship today.
>
> Bob's right, the version number from uname only tells you about
> the kernel, and not whether, for example, the Cocoa API is on the
> system (it wouldn't be on a standalone Darwin OS install, which
> will have the same uname output).
>
> Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/
> SystemVersion.plist, which is XML. If you want that info, parsing
> the file may be more efficient than forking off sw_vers.
>
> -wsv
>
>
> On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
>
>
>> I forgot. The current code recognizes 'Rhapsody' and maps it to
>> "MacOS
>> X Server". But I don't see any evidence that Apple still uses the
>> code
>> name Rhapsody. Does uname ever return 'Rhapsody'?
>>
>
>
___
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] Visibility scope for "for/while/if" statements
Hello Josiah,
>> Why the variables defined inside "for"/"while"/"if" statements
>> (including loop variables for "for") are visible outside this scope?
JC> if and while statements don't define variables, so they can't expose
JC> them later in the scope.
They don't. They just leak internal ones:
i = 0
while i != 1:
i += 1
j = 5
print j
JC> In regards to 'for' loops, they have always done that, there is code
JC> that relies on that behavior, and changing behavior would unnecessarily
JC> break code.
I mentioned it below: while unconditional changing the behaviour will
definitely break a lot, something like "import strict" would help
those ones who rate such behaviour enough error-prone to
reconsider proceeding using Python at all.
JC> Further, you should clarify what you would want this mythical non-leaky
JC> for loop to do in various cases. What would happen in the following
JC> case?
JC> i = None
JC> for i in ...:
JC> ...
JC> print i
JC> ... assuming that the loop executed more than once? Would you always
JC> get 'None' printed, or would you get the content of the last variable?
As for me (if my humble opinion is useful for you), the best would be
to 1. assume that a loop variable is always newly-declared for this
loop, 2. all variables first declared inside the loop are local to this
loop.
Thus, your example falls to case 1: "i" variable is newly declared for
this loop. Well, we don't reuse old value of i to start the iteration
from a particular place, like below?
i = 5
for i in [3,4,5,6,7]:
print i,
More general, the variables could be assumed local only to the *same
or higher* indentation level.
JC> What about:
JC> x = None
JC> for i in ...:
JC> x = f(i)
JC> ...
JC> print x
JC> Would 'x' be kept after the loop finished executing?
case 2: "x" variable is declared already. And if there is no
"x = None" line, it should tell "name 'x' is not defined". Unless we
are prone to funny "uncertainly defined" cases, if some variable is
defined inside an "in" in the loop.
JC> I would imagine in your current code you are running something like
JC> this:
JC> i = #some important value
JC> ... #many lines of code
JC> for i in ...:
JC> ...
JC> #you access the 'i' you bound a long time ago
JC> In this case, you are making a common new programmer mistake by using
JC> the same variable name for two disparate concepts.
Nah, here is my error-case:
I made several loops, one by one, using the "i" variable for looping.
Then in the latest loop I changed the "i" name to more meaningful
"imsi" name in the "for" declaration and whenever I found inside the loop.
As I use "i" name *for loops exclusively*, I didn't wittingly reuse the
same name for different purposes. The problem was that I missed one
occurance of "i" variable inside the loop code, so it gained the same
value (from the completion of previous loop) throughout all the "imsi"
loop. And the interpreter didn't notice me that "I am using the
undefined variable" (since it is considered defined in Python), as
accustomed from other languages. That's my sorrowful story.
JC> If the 'i' that was
JC> initially bound was important through the lifetime of the scope, you
JC> should have named it differently than the 'i' that was merely a loop
JC> variable.
I'm pretty happy that I didn't ever made a list comprehension with "i"
variable inside the loop over "i" variable. While I wasn't aware of
these side-effects, it would be even harder spottable. Now I'll look
more carefully at copy-pasting list comprehensions, in every case
examining all of the lower-indent variables for not to clash.
JC> I will also point out that in general, not leaking/exposing/etc. such
JC> variables would necessarily slow down Python. Why?
I agree, this is one of obvious advantages of absence of
pseudo-namespaces (wasting the resources to allocation and removal of
variables, etc). Though in case of presence of pseudo-namespaces, it
an easily be emulated by initializing the variable first-time on the
highest-level of indentation.
But for the "performance-oriented/human-friendliness" factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
JC> Python semantics seem to have been following the rule of "we are all
JC> adults here".
I always believed that the programming language (as any computer
program) should slave to the human, rather than a human should slave
to the program.
JC> Generally though, Python follows a common C semantic of variable leakage.
JC> C Code:
JC> int i; // required in some versions of C
JC> for (i=0;i<10;i++) {
JC> ...
JC> }
"for (int i = 0; i < 10; i++)" works fine nowadays.
JC> Again: test your assumptions. If your untested assumptions are wrong,
JC> don't complain that the language is broken.
In my case, as I explained already, it was not a assumption but an
uncatched mistype, which is usually catched in other languages d
[Python-Dev] GIL, Python 3, and MP vs. UP
Ok. While windows already prefers threads, while linux-2.6 improves thread support and speed, while process startup expensive on time and memory, while we ought to dublicate our data and/or use obscure shared memory, while it is much simpler to make threaded program with care just about locks than multiprocessing with inventing interchange protocol (which abuses both CPU - sender and reciever), MULTIPROCESSING RULES!!! And on Opterons: you will win with multiprocessing ONLY if OS will bind process and processor/memory place pair. That would be difficult. Guido van Rossum wrote: > That's an understatement. I expect that *most* problems (even most > problems that we will be programming 10-20 years from now) get little > benefit out of MP. They are allready here. Servers they are. It is so simple to write application server in Python. It is so difficult to make it scallable in CPython. Hardware is cheap, development time is expensive. To make scallable CPython-backed server one needs too much time. And he goes to Java, .NET and others (and rare to Jython, IronPython (in the future)). CPython will not be wide popular without real multithreading. --I want my Apache, written in Python ! :-) --I want my MySQL, written in Python ! ;-) It is a joke. But every joke has a peace of truth (as russian sayes). (Excuse my English) ___ 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] vendor-packages directory
Hi, Recently I asked about the inclusion of a "vendor-packages" directory for Python on the Python mailing list. See the thread started at: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request, and the replies I received. I then approached Guido for his take on this suggestion. He recommended I submit the patch to the Python patch manager at SourceForge, and inform the folks on python-dev mailing list. So I have. You can find the patch submission at: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 Thanks. -- Rich Burridge Email: [EMAIL PROTECTED] Sun Microsystems Inc. (MPK14-260), Phone: +1.650.786.5188 4150 Network Circle,AIM/YAHOO: RicBurridge Santa Clara, CA 95054 Blog: http://blogs.sun.com/richb ___ 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today. Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output). Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ SystemVersion.plist, which is XML. If you want that info, parsing the file may be more efficient than forking off sw_vers. -wsv On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote: I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'? smime.p7s Description: S/MIME cryptographic 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
Shockingly, it even says that parsing the file is "a better way"
than using gestaltSystemVersion().
It's better for python, anyway, I think, since it doesn't require
access to the Carbon API set. Be sure to handle the case where the
file doesn't exist:
import os
version_info_file = "/System/Library/CoreServices/
SystemVersion.plist"
if os.path.isfile(version_info_file):
import plistlib
info = plistlib.Plist.fromFile(version_info_file)
print '%(ProductName)s %(ProductVersion)s' % info
else:
uname_os, uname_version = do_the_uname_thing
print '%s %s' % (uname_os, uname_version)
Or similar.
-wsv
On Sep 22, 2005, at 10:10 AM, Bob Ippolito wrote:
/usr/bin/sw_vers technically calls a private (at least undocumented)
CoreFoundation API, it doesn't parse that plist directly :)
On further inspection, it looks like parsing the plist directly is
supported API these days (see the bottom of ):
import plistlib
dct = plistlib.Plist.fromFile('/System/Library/CoreServices/
SystemVersion.plist')
print '%(ProductName)s %(ProductVersion)s' % dct
-bob
On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on
anything we ship today.
Bob's right, the version number from uname only tells you about
the kernel, and not whether, for example, the Cocoa API is on the
system (it wouldn't be on a standalone Darwin OS install, which
will have the same uname output).
Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/
SystemVersion.plist, which is XML. If you want that info, parsing
the file may be more efficient than forking off sw_vers.
-wsv
On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
I forgot. The current code recognizes 'Rhapsody' and maps it to
"MacOS
X Server". But I don't see any evidence that Apple still uses the
code
name Rhapsody. Does uname ever return 'Rhapsody'?
___
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/
wsanchez%40wsanchez.net
smime.p7s
Description: S/MIME cryptographic 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
IIRC, it doesn't exist on such a system; that's a Mac OS command, not a Darwin command. (The man page correctly has "Mac OS X" in the footnote, not "Darwin" or "BSD", though I don't know that you can rely on that 100%.) -wsv On Sep 22, 2005, at 10:20 AM, Guido van Rossum wrote: On 9/22/05, Wilfredo Sánchez Vega <[EMAIL PROTECTED]> wrote: "rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today. Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output). Just curious -- what would sw_vers print on such a system? smime.p7s Description: S/MIME cryptographic 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] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Jeremy Maxfield <[EMAIL PROTECTED]> writes: > Sorry I think you're 'much mistaken'... > > The revision of PyState.c in the rc242c1 looks like 2.38.22 (should be > 2.42) > and threadmodule.c looks like 2.59 (should be 2.64) Looks like you're right but SF CVS is being *astonishingly* slow right now. The fixes will be in 2.4.2. Cheers, mwh -- There are 'infinite' number of developed artifacts and one cannot develop appreciation for them all. It would be all right to not understand something, but it would be imbecilic to put judgements on things one don't understand. -- Xah, comp.lang.lisp ___ 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] Visibility scope for "for/while/if" statements
Alexander Myodov wrote: > Thus, your example falls to case 1: "i" variable is newly declared for > this loop. Well, we don't reuse old value of i to start the iteration > from a particular place, like below? > > i = 5 > for i in [3,4,5,6,7]: > print i, > > More general, the variables could be assumed local only to the *same > or higher* indentation level. So (since you're talking about "if" as well as "for" and "while") you're suggesting that x = 0 if foo(): x = 1 else: x = 2 should always leave x == 0? Or that the same bit of code, without the first line, should always leave x undefined? > JC> Python semantics seem to have been following the rule of "we are all > JC> adults here". > > I always believed that the programming language (as any computer > program) should slave to the human, rather than a human should slave > to the program. Right. And some of us humans *don't want* the change you're proposing. For what it's worth, I think it might well have been better if "for" and comprehensions had made their loop variables block-local; especially comprehensions. But making every for/while/if introduce a new level of scoping would be horrible. Perhaps you think it's what you want, but I think if you tried it for a month then you'd change your mind. -- g ___ 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] GIL, Python 3, and MP vs. UP
On Thu, Sep 22, 2005 at 10:27:10AM +0400, Sokolov Yura wrote: > MULTIPROCESSING RULES!!! Everything in programming is about "divide and conquer". Separate and control. Modules. Classes. Namespaces. And now that multithreading with shared memory. That's an evil idea, it causes a lot of troubles, it requires locks and semaphores, and still leads to problems. Shared memory is evil. Multithreading is harmful. > Hardware is cheap, development time is expensive. Yes. Do not spend developer's time finding bugs in locks and semaphores, fixing race conditions, etc. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Visibility scope for "for/while/if" statements
"Alexander Myodov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Why the variables defined inside "for"/"while"/"if" statements > (including loop variables for "for") are visible outside this scope? Questions about why Python is the way it is belong on comp.lang.python, the general Python mailing list, or gmane.comp.python.general (they are all gatewayed to each other). Moreover, they are likely to have been asked, answered, and discussed previously, with the answers possibly discoverable thru Google search of the c.l.p archives. This one certainly has been. ___ 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] GIL, Python 3, and MP vs. UP
At 10:27 AM 9/22/2005 +0400, Sokolov Yura wrote: >It is so simple to write application server in Python. >It is so difficult to make it scallable in CPython. It seems you've never heard of fork(), which works just fine to scale Python processes on multiprocessor boxes. I've actually done this, and it didn't take a lot of time to implement, so I don't know what you're talking about here. ___ 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] vendor-packages directory
At 08:19 AM 9/22/2005 -0700, Rich Burridge wrote: >Hi, > >Recently I asked about the inclusion of a "vendor-packages" >directory for Python on the Python mailing list. > >See the thread started at: > >http://mail.python.org/pipermail/python-list/2005-September/300029.html > >for the full reasoning behind this request, and the replies >I received. I'm with Terry on this, it needs a better rationale. Why can't you just add a .pth file to the site-packages directory? It seems that would address the issue nicely. (See http://docs.python.org/lib/module-site.html for documentation of the .pth mechanism, which would let you implement a separate vendor-packages directory without modifying Python, and would still allow local overrides of your vendor packages.) ___ 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] GIL, Python 3, and MP vs. UP
Phillip J. Eby wrote: >>It is so simple to write application server in Python. >>It is so difficult to make it scallable in CPython. > > It seems you've never heard of fork(), which works just fine to scale > Python processes on multiprocessor boxes. there's a version of fork hidden somewhere in CPython that solves all interprocess communication and synchronization issues? cool. ___ 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] Visibility scope for "for/while/if" statements
Alexander Myodov <[EMAIL PROTECTED]> wrote:
[snip Alexander Myodov complaining about how Python works]
> i = 0
> while i != 1:
> i += 1
> j = 5
> print j
Maybe you don't realize this, but C's while also 'leaks' internal
variables...
int i = 0, j;
while (i != 1) {
i++;
j = 5;
}
printf("%i %i\n", i, j);
If you haven't yet found a good use for such 'leakage', you should spend
more time programming and less time talking; you would find (quite
readily) that such 'leaking' is quite beneficial.
> I made several loops, one by one, using the "i" variable for looping.
> Then in the latest loop I changed the "i" name to more meaningful
> "imsi" name in the "for" declaration and whenever I found inside the loop.
> As I use "i" name *for loops exclusively*, I didn't wittingly reuse the
> same name for different purposes. The problem was that I missed one
> occurance of "i" variable inside the loop code, so it gained the same
> value (from the completion of previous loop) throughout all the "imsi"
> loop. And the interpreter didn't notice me that "I am using the
> undefined variable" (since it is considered defined in Python), as
> accustomed from other languages. That's my sorrowful story.
So you mistyped something. I'm crying for you, really I am.
> But for the "performance-oriented/human-friendliness" factor, Python
> is anyway not a rival to C and similar lowlevellers. C has
> pseudo-namespaces, though.
C does not have pseudo-namespaces or variable encapsulation in for loops.
Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
does not rival C in the performance/friendliness realm? Who are you
trying to kid? There is a reason why high school teachers are teaching
kids Python instead of Pascal, Java, etc., it's because it is easier to
learn and use. On the performance realm, of course Python is beat out
by low-level languages; it was never meant to compete with them. Python
does what it can for speed when such speed does not affect the usability
of the language. What you are proposing both would reduce speed and
usability, which suggests that it wasn't a good idea in the first place.
> JC> Python semantics seem to have been following the rule of "we are all
> JC> adults here".
> I always believed that the programming language (as any computer
> program) should slave to the human, rather than a human should slave
> to the program.
Your beliefs were unfounded. If you look at every programming language,
there are specific semantics and syntax for all of them. If you fail to
use and/or understand them, the langauge will not be your 'slave'; it
will not run correctly, if at all.
> "for (int i = 0; i < 10; i++)" works fine nowadays.
I'm sorry, but you are wrong. The C99 spec states that you must define
the type of i before using it in the loop. Maybe you are thinking of
C++, which allows such things.
> JC> Also: python-dev is a mailing list for the development /of/ Python.
> JC> Being that your questions as of late have been in the realm of "why does
> JC> or doesn't Python do this?", you should go to python-list (or the
> JC> equivalent comp.lang.python newsgroup) for answers to questions
> JC> regarding current Python behavior, and why Python did or didn't do
> JC> something in its past.
> I'm sorry for wasting the time of developers. For "for/while/if"
> statements, I just had an idea which (I believed) could be useful for
> many peoples,
Test your ideas on comp.lang.python first, when more than a handful of
people agree with you, come back.
- Josiah
___
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] Compressing MSI files: 2.4.2 candidate?
I just found that I can save somewhat more than 1MiB in the MSI file by using LZX:21 instead of the standard MSZIP when compressing the CAB file. A resulting package can be found at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.2c1.msi Can people please test whether this installs just as well? Is it ok to use this modified procedure for 2.4.2 final (2.4.2c1 still uses MSZIP). 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] GIL, Python 3, and MP vs. UP
On Mon, Sep 19, 2005 at 09:12:05PM +0100, Michael Hudson wrote: > Martin Blais <[EMAIL PROTECTED]> writes: > > On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >> On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: > >> > I realize that not all algorithms (nor all computational problems) scale > >> > well to MP hardware. Is it feasible to usefully compile both MP and a UP > >> > binaries from one Python source code base? > >> > >> That's an understatement. I expect that *most* problems (even most > >> problems that we will be programming 10-20 years from now) get little > >> benefit out of MP. > > > > Some are saying it won't be a matter of choice if we want to get the > > software to run faster (you know, that "MORE MORE MORE!" thing we all > > seem to suffer from): > > People have been saying this for _years_, and it hasn't happened yet. > This time around it's a bit more convincing, but I reserve the right > to remain a touch skeptical. good! :) > > http://www.gotw.ca/publications/concurrency-ddj.htm > > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software > > Herb Sutter > > March 2005 > > I was disappointed that that article (hey, it was the only issue of > ddj I've ever actually bought! :) didn't consider any concurrency > models other than shared memory threading. Beware. Multi-core and/or multi-threaded cpus are the only thing the high end CPU manufacturers are able to produce today that they can still claim to be "faster." There is a HUGE incentive for them to create demand for their design lest it become irrelevant and they be forced to sell only low-margin commodity single core hardware. This means we'll see a ton of papers and people paid or coerced into suggesting that this is the best thing since time sliced bread. -g ___ 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] vendor-packages directory
Phillip J. Eby wrote: >> Recently I asked about the inclusion of a "vendor-packages" >> directory for Python on the Python mailing list. >> >> See the thread started at: >> >> >> http://mail.python.org/pipermail/python-list/2005-September/300029.html >> >> for the full reasoning behind this request, and the replies >> I received. > > > I'm with Terry on this, it needs a better rationale. Why can't you just > add a .pth file to the site-packages directory? It seems that would > address the issue nicely. > > (See http://docs.python.org/lib/module-site.html for documentation of > the .pth mechanism, which would let you implement a separate > vendor-packages directory without modifying Python, and would still > allow local overrides of your vendor packages.) I understand how .pth files work. The rationale for requesting the "vendor-packages" approach, is that Python files, as supplied by the vendor (Sun, Apple, RedHat ...) with their operating system software, should go in a totally separate base directory, to differentiate them from Python files installed specifically at one site. ___ 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] vendor-packages directory
At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote: >Phillip J. Eby wrote: >>>Recently I asked about the inclusion of a "vendor-packages" >>>directory for Python on the Python mailing list. >>> >>>See the thread started at: >>> >>>http://mail.python.org/pipermail/python-list/2005-September/300029.html >>> >>>for the full reasoning behind this request, and the replies >>>I received. >> >>I'm with Terry on this, it needs a better rationale. Why can't you just >>add a .pth file to the site-packages directory? It seems that would >>address the issue nicely. >>(See http://docs.python.org/lib/module-site.html for documentation of the >>.pth mechanism, which would let you implement a separate vendor-packages >>directory without modifying Python, and would still allow local overrides >>of your vendor packages.) > >I understand how .pth files work. > >The rationale for requesting the "vendor-packages" approach, is that >Python files, >as supplied by the vendor (Sun, Apple, RedHat ...) with their operating >system >software, should go in a totally separate base directory, to differentiate >them >from Python files installed specifically at one site. Right - I'm proposing you add a vendor-packages.pth file to site-pacakges, that points to a "totally separate base directory" where those files are installed, not that you install the packages themselves under site-packages. To make sure we're disagreeing about the same thing <0.5 wink>, here's what I'm suggesting: 1. Install your packages in /usr/lib/python2.4/vendor-packages (so far, so good, we agree on this part) 2. Create a 'vendor-packages.pth' file in /usr/lib/python2.4/site-packages, containing the line: /usr/lib/python2.4/vendor-packages This will ensure that your vendor-packages "just work", unless locally overridden in site-packages. So, you install one .pth file, once, as part of your installation of Python itself, and it works *now*, without waiting for a new Python release or complicating any other Python code or requiring agreement between vendors about how to do this. This is one of the things that .pth files are for, and I believe it should be the recommended way for operating systems to establish OS-specific modifications to the default Python module search path. Otherwise, everybody will be patching site.py for their specific OS, and there are already too many OS-specific things in that code, and for backward-compatibility reasons we can't get rid of them in Python 2.x. I don't think we want to add new ones. ___ 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] GIL, Python 3, and MP vs. UP
At 08:42 PM 9/22/2005 +0200, Fredrik Lundh wrote: >Phillip J. Eby wrote: > >At 10:27 AM 9/22/2005 +0400, Sokolov Yura wrote: > >>It is so simple to write application server in Python. > >>It is so difficult to make it scallable in CPython. > > > > It seems you've never heard of fork(), which works just fine to scale > > Python processes on multiprocessor boxes. > >there's a version of fork hidden somewhere in CPython that solves all >interprocess communication and synchronization issues? cool. Yep, it's called "fork stateless application servers that keep their state in a relational database." <0.1 wink> It works for an astonishingly wide assortment of business problems, anyway. :) Don't get me wrong, I'm not opposed to adding better IPC capabilities; a Linda-like IPC facility would be nice to have, too. I was just pointing out the fallacy in the original post (whose attribution you deleted for some reason), that *scalability* is the issue. The original poster was claiming (in effect) that IPC and synchronization are trivial and that the GIL is responsible for some mythical lack of "scalability". Threads can't scale past one machine, no matter how many processors you put in it, so it's a red herring IMO. ___ 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] vendor-packages directory
On Sep 22, 2005, at 3:56 PM, Phillip J. Eby wrote:
> At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote:
>
>> Phillip J. Eby wrote:
>>
Recently I asked about the inclusion of a "vendor-packages"
directory for Python on the Python mailing list.
See the thread started at:
http://mail.python.org/pipermail/python-list/2005-September/
300029.html
for the full reasoning behind this request, and the replies
I received.
>>>
>>> I'm with Terry on this, it needs a better rationale. Why can't
>>> you just
>>> add a .pth file to the site-packages directory? It seems that would
>>> address the issue nicely.
>>> (See http://docs.python.org/lib/module-site.html for
>>> documentation of the
>>> .pth mechanism, which would let you implement a separate vendor-
>>> packages
>>> directory without modifying Python, and would still allow local
>>> overrides
>>> of your vendor packages.)
>>>
>>
>> I understand how .pth files work.
>>
>> The rationale for requesting the "vendor-packages" approach, is that
>> Python files,
>> as supplied by the vendor (Sun, Apple, RedHat ...) with their
>> operating
>> system
>> software, should go in a totally separate base directory, to
>> differentiate
>> them
>> from Python files installed specifically at one site.
>>
>
> Right - I'm proposing you add a vendor-packages.pth file to site-
> pacakges,
> that points to a "totally separate base directory" where those
> files are
> installed, not that you install the packages themselves under
> site-packages. To make sure we're disagreeing about the same thing
> <0.5
> wink>, here's what I'm suggesting:
>
> 1. Install your packages in /usr/lib/python2.4/vendor-packages (so
> far, so
> good, we agree on this part)
>
> 2. Create a 'vendor-packages.pth' file in /usr/lib/python2.4/site-
> packages,
> containing the line:
>
> /usr/lib/python2.4/vendor-packages
>
> This will ensure that your vendor-packages "just work", unless locally
> overridden in site-packages.
vendor-packages.pth should look like this (evil, but practical):
import site; site.addsitedir('/usr/lib/python2.4/vendor-packages')
Otherwise packages like Numeric, PIL, PyObjC, etc. that take
advantage of pth files will not work when installed to that location.
-bob
___
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] vendor-packages directory
On Sep 22, 2005, at 3:04 PM, Rich Burridge wrote:
> Phillip J. Eby wrote:
>
>>> Recently I asked about the inclusion of a "vendor-packages"
>>> directory for Python on the Python mailing list.
>>>
>>> See the thread started at:
>>>
>>>
>>> http://mail.python.org/pipermail/python-list/2005-September/
>>> 300029.html
>>>
>>> for the full reasoning behind this request, and the replies
>>> I received.
>>>
>>
>>
>> I'm with Terry on this, it needs a better rationale. Why can't
>> you just
>> add a .pth file to the site-packages directory? It seems that would
>> address the issue nicely.
>>
>> (See http://docs.python.org/lib/module-site.html for documentation of
>> the .pth mechanism, which would let you implement a separate
>> vendor-packages directory without modifying Python, and would still
>> allow local overrides of your vendor packages.)
>>
>
> I understand how .pth files work.
>
> The rationale for requesting the "vendor-packages" approach, is
> that Python files,
> as supplied by the vendor (Sun, Apple, RedHat ...) with their
> operating system
> software, should go in a totally separate base directory, to
> differentiate them
> from Python files installed specifically at one site.
Note that Apple already does this via a .pth file ("Extras.pth"), as
of Mac OS X 10.4, which points to the following location:
/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/
python
Currently this location includes wxPython. There is an additional
vendor package which they (wrongly) integrated into their patched
Python build process so it ends up in the plat-mac subsection of the
standard library (CoreGraphics). This is a closed-source not-very-
well-done SWIG generated CoreGraphics wrapper that they use for some
print filters and such.
Note that Python does have additional support on Mac OS X for an
additional per-user site directory out of the box (for framework
style builds anyway):
~/Library/PythonX.Y/site-packages/
There's also the admin-writable /Library/PythonX.Y/site-packages/,
but that's an implementation detail in that Apple made site-packages
a symlink to that location.
-bob
___
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] Visibility scope for "for/while/if" statements
Hello Josiah,
>> i = 0
>> while i != 1:
>> i += 1
>> j = 5
>> print j
JC> Maybe you don't realize this, but C's while also 'leaks' internal
JC> variables...
JC> int i = 0, j;
JC> while (i != 1) {
JC> i++;
JC> j = 5;
JC> }
JC> printf("%i %i\n", i, j);
Yeah, it may *leak* it in your example. But the advantage is that it
may *not leak* as well:
for (int i = 0; i <= 5; i++) { int j = 5; }
printf ("%i\n", j); // Won't be even compiled
Or in our "while" case:
int i = 0;
while (i != 1) {
i++;
int j = 5;
}
printf("%i %i\n", i, j);
JC> If you haven't yet found a good use for such 'leakage', you should spend
JC> more time programming and less time talking; you would find (quite
JC> readily) that such 'leaking' is quite beneficial.
I see such usages and realize the possible gains from it. But for
about five years of software development in a bunch of programming
languages, I've found good uses of non-leaking variables *as well*. Up
to the level of manually "enclosing" the temporary variables used only
once:
...
int i = input();
int result;
{
int j = f1(i);
int k = f2(i, j);
result = f3(i, j, k);
} // Now j and k are dead
...
>> accustomed from other languages. That's my sorrowful story.
JC> So you mistyped something. I'm crying for you, really I am.
Yeah, I did. Just forgot removing the usage / renaming of variable neved
initialized (I thought) before. And my error was that I relied upon
the interpreter to catch it, mistakenly assuming the locality of
variables inside loops as a consistency with other common languages.
Mea culpa, without any jeers. The only reason why I was wrote my email
was to get the understanding of community assessment of such
behaviour, and/or probable workarounds. No blame against Python - it's
great even with this unusualty.
>> But for the "performance-oriented/human-friendliness" factor, Python
>> is anyway not a rival to C and similar lowlevellers. C has
>> pseudo-namespaces, though.
JC> C does not have pseudo-namespaces or variable encapsulation in for loops.
Neither
for (int i = 0; i <= 5; i++) { int j = 5; }
printf ("%i\n", i);
nor
for (int i = 0; i <= 5; i++) { int j = 5; }
printf ("%i\n", j);
gets compiled though with "gcc -std=c99". That is, each loop
introduces a new scoping level.
JC> Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
JC> does not rival C in the performance/friendliness realm? Who are you
JC> trying to kid? There is a reason why high school teachers are teaching
JC> kids Python instead of Pascal, Java, etc., it's because it is easier to
JC> learn and use.
Ohh, my slip made me considered a troll... I meant only that Python
does not rival C in such area as "performance by all means, even with
decrease of friendliness" (but the overall performance is indeed good,
I've seen even the VoIP solution written purely on on Python). And I
believe noone of Python developers want it to be rival.
JC> What you are proposing both would reduce speed and
JC> usability, which suggests that it wasn't a good idea in the first place.
Yes, it lacks performance, but I still believe that an opportunity to close the
visibility of variables (*opportunity* rather than *behaviour
change*!) is better in terms of "friendliness" rather than lack of it.
Just because it offers the alternatives. Because C-style closed
visibility can emulate the variable lack, but not vice versa.
At least one voice here (of Gareth McCaughan) is not-strictly-against
it. So I cannot agree that such *option* can reduce usability.
>> "for (int i = 0; i < 10; i++)" works fine nowadays.
JC> I'm sorry, but you are wrong. The C99 spec states that you must define
JC> the type of i before using it in the loop. Maybe you are thinking of
JC> C++, which allows such things.
"gcc -std=c99" compiles the line "for (int i = 0; i <= 5; i++);"
perfectly. Along with another sample mentioned above .
To this day, I relied upon gcc in terms of standards compatibility...
JC> Tes your ideas on comp.lang.python first, when more than a handful of
JC> people agree with you, come back.
Ok. Next time I shall be more careful. Sorry again, and thanks for
your time. And thanks for more-or-less patient answers.
--
With best regards,
Alexander mailto:[EMAIL PROTECTED]
___
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] vendor-packages directory
At 01:18 PM 9/22/2005 -0700, Rich Burridge wrote:
>Phillip J. Eby wrote:
>>Right - I'm proposing you add a vendor-packages.pth file to
>>site-pacakges, that points to a "totally separate base directory" where
>>those files are installed, not that you install the packages themselves
>>under site-packages. To make sure we're disagreeing about the same thing
>><0.5 wink>, here's what I'm suggesting:
>>1. Install your packages in /usr/lib/python2.4/vendor-packages (so far,
>>so good, we agree on this part)
>>2. Create a 'vendor-packages.pth' file in
>>/usr/lib/python2.4/site-packages, containing the line:
>>/usr/lib/python2.4/vendor-packages
>>This will ensure that your vendor-packages "just work", unless locally
>>overridden in site-packages.
>>So, you install one .pth file, once, as part of your installation of
>>Python itself, and it works *now*, without waiting for a new Python
>>release or complicating any other Python code or requiring agreement
>>between vendors about how to do this. This is one of the things that
>>.pth files are for, and I believe it should be the recommended way for
>>operating systems to establish OS-specific modifications to the default
>>Python module search path. Otherwise, everybody will be patching site.py
>>for their specific OS, and there are already too many OS-specific things
>>in that code, and for backward-compatibility reasons we can't get rid of
>>them in Python 2.x. I don't think we want to add new ones.
>
>Bob Ippolito wrote:
> > vendor-packages.pth should look like this (evil, but practical):
> >
> > import site; site.addsitedir('/usr/lib/python2.4/vendor-packages')
> >
> > Otherwise packages like Numeric, PIL, PyObjC, etc. that take advantage
> > of pth files will not work when installed to that location.
>
>Thanks! I'll work with the architectural committee in question to see if they
>are happy with this approach to solving the problem.
Glad we could help. Unfortunately, there isn't any sort of document at the
moment for "Python Distributors" to help explain how these kinds of
problems should be solved. It would probably be a good idea for us to have
one. Perhaps a volunteer or two could be found on the distutils-SIG who
could help put one together, since a certain number of distributions'
Python gurus tend to hang out there.
(By the way, assuming this solves your problem fully, don't forget to
withdraw your patch on SF, optionally citing the python.org archive URL for
this email.)
___
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] os.path.diff(path1, path2) (and a first post)
On Sat, 17 Sep 2005, John J Lee wrote: > > On Fri, 16 Sep 2005, Greg Ewing wrote: > > > Trent Mick wrote: > > > > > If this *does* get added (I'm +0) then let's call it "relpath" or > > > "relpathto" as in the various implementations out there: > > > > +1 on that, too. Preferably just "relpath". > [...] > > +1 on adding this function, and on "relpath" as the name. I wanted this > function just a few weeks ago. Hello All, This is my first post here, so first a few words about me. My name is Richard Barran. I live in Paris (but I'm English) and earn my living by coding Oracle stored procedures in PL/SQL. I discovered Python 2 years ago and now use it in my day job for a variety of purposes: quick scripts, unit testing of my "proper" PL/SQL stuff, code deployment scripts and so on. Now down to business: I'm the author of one of the "relpath" functions posted on the ActiveState website* so I've read this thread with interest. For some time I've been thinking of contributing something back to Python, but I thought the relpath function was too specialised for inclusion in the standard library. Also I wasn't clear on how to go about getting the support of a python-dev member, as required in the development process guidelines paper :-) So I have a question: do the previous mails mean that a relpath function might possibly be a usefull addition to os.path? And if the answer to the previous question is "yes", then should I submit a patch, or is someone else already working on it? Regards, Richard Barran * my version is the one at http://aspn.activestate.com/ASPN/Cookbook/ Python/Recipe/302594 ___ 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] Visibility scope for "for/while/if" statements
Alexander Myodov <[EMAIL PROTECTED]> wrote: > >> "for (int i = 0; i < 10; i++)" works fine nowadays. > JC> I'm sorry, but you are wrong. The C99 spec states that you must define > JC> the type of i before using it in the loop. Maybe you are thinking of > JC> C++, which allows such things. > "gcc -std=c99" compiles the line "for (int i = 0; i <= 5; i++);" > perfectly. Along with another sample mentioned above . > To this day, I relied upon gcc in terms of standards compatibility... I misread the error message from my compiler. It /only/ works in C99 mode. Previous C standards (which CPython itself conforms to) did not allow such things. Interestingly enough, not all C++ compilers (Microsoft) hid variables created in for loops (http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2). - Josiah ___ 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] Visibility scope for "for/while/if" statements
Please end this thread. It belongs in c.l.py. Nothing's going to change. -- --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] GIL, Python 3, and MP vs. UP
Sokolov Jura writes: > It is so simple to write application server in Python. > It is so difficult to make it scallable in CPython. > CPython will not be wide popular without real multithreading. He's right. Bill ___ 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] GIL, Python 3, and MP vs. UP
"Bill Janssen" <[EMAIL PROTECTED]> wrote in message news:05Sep22.141518pdt."58617"@synergy1.parc.xerox.com... > Sokolov Jura writes: >> It is so simple to write application server in Python. >> It is so difficult to make it scallable in CPython. >> CPython will not be wide popular without real multithreading. > > He's right. I think the post is at least somewhat wrong on both technical and topicalness levels. On a technical level, the second statement seems wrong as an absolute statement. Phillip Eby claims that *some* application servers are easily scaled even if others are not. I suspect this is more likely to be the truth. In any case, the statement conveys no new technical information while to me it has the form and emotional load of a flame. The third statement is an opinion about the indefinite future which is neither right nor wrong as it stands. To ever judge it so, we need an operational definition of 'wide popular' to guide measurement. By some standards, Python is already widely popular. By others, it never will be. Guido already said that he will consider a high-quality maintainable 'real threading' patch that proves his scepticism wrong and that is neutral to beneficial to most all users, so I see little point in further flogging the issue, at least on this forum. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2) (and a first post)
[richard barran wrote] > So I have a question: do the previous mails mean that a relpath > function might possibly be a usefull addition to os.path? Yes, it seems to have support. > And if the answer to the previous question is "yes", then should I > submit a patch, or is someone else already working on it? Yes, please do. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] os.path.diff(path1, path2) (and a first post)
On Sep 22, 2005, at 8:58 PM, Trent Mick wrote: > [richard barran wrote] > >> So I have a question: do the previous mails mean that a relpath >> function might possibly be a usefull addition to os.path? >> > > Yes, it seems to have support. I'd like to throw in another late +1 here, I've written this myself more times than I care to count. -bob ___ 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] bool(iter([])) changed between 2.3 and 2.4
Jim Jewett wrote: > "Is there anything left?" is a pretty analogy for iterators, > particularly since the examples tend to start with list > or file iterators. But this can't be supported by all iterators, so it would be something special to these iterators. Keeping track of the peculiarities of iterators associated with particular types is too much to fit in my brain. I'd rather they all had the same interface. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Visibility scope for "for/while/if" statements
Josiah Carlson wrote: > As for list comprehensions, they were literally meant to be a > completely equivalent translation of a set of for loops. I don't think that's quite true. I doubt whether anyone really thought about the issue when LCs were first being discussed. I didn't, but if I had, I wouldn't have considered the variable-leaking as being something that it was necessary to preserve, because the only use case for it is something you can't do with an LC anyway. The reasons for the variable-leaking being preserved are (1) it fell out of the implementation and (2) it makes the documentation slightly simpler, since LCs can be described fully and accurately in terms of translation to for-loops. Whether those are *good* reasons or not is debatable. In Py3k it's possible that this will be resolved by making for-loop variables local to the loop as well. Or maybe not. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Visibility scope for "for/while/if" statements
On 9/22/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > As for list comprehensions, they were literally meant to be a > > completely equivalent translation of a set of for loops. > > I don't think that's quite true. I doubt whether anyone > really thought about the issue when LCs were first being > discussed. I didn't, but if I had, I wouldn't have > considered the variable-leaking as being something that > it was necessary to preserve, because the only use case > for it is something you can't do with an LC anyway. > > The reasons for the variable-leaking being preserved are > (1) it fell out of the implementation and (2) it makes the > documentation slightly simpler, since LCs can be described > fully and accurately in terms of translation to for-loops. > > Whether those are *good* reasons or not is debatable. It was the cheapest implementation; it was known at the time that it wasn't ideal. I'd like to fix this in 3.0, so that LC's are just a special case of GE's. > In Py3k it's possible that this will be resolved by making > for-loop variables local to the loop as well. Or maybe not. Definitely not. There are lots of uses for the loop control variable after break. -- --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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 337 open ( -6) / 2941 closed (+14) / 3278 total ( +8) Bugs: 908 open ( +0) / 5262 closed (+17) / 6170 total (+17) RFE : 194 open ( +5) / 187 closed ( +2) / 381 total ( +7) New / Reopened Patches __ use LIST_APPEND opcode for X.append() method calls (2005-09-16) http://python.org/sf/1292625 opened by Neal Norwitz python.sty correction - verbatim environment (2005-09-17) http://python.org/sf/1293788 opened by Wojciech Smigaj python.sty: [EMAIL PROTECTED] correction (2005-09-17) http://python.org/sf/1293790 opened by Wojciech Smigaj cjkcodecs does not initialize type pointer (2005-09-20) http://python.org/sf/1297028 opened by Eric Huss "Fatal Python error" from cStringIO's writelines (2005-09-22) CLOSED http://python.org/sf/1298449 opened by Andrew Bennetts Unchecked return value in cStringIO (2005-09-22) CLOSED http://python.org/sf/1298499 opened by Andrew Bennetts sysmodule.c: realpath() is unsafe (2005-09-22) http://python.org/sf/1298813 opened by Mihai Ibanescu vendor-packages directory. (2005-09-22) http://python.org/sf/1298835 opened by Rich Burridge Patches Closed __ Simple webbrowser fix for netscape -remote (2004-12-02) http://python.org/sf/1077979 closed by birkenfeld Replacement for webbrowser.py which has problems. (2004-05-16) http://python.org/sf/954628 closed by birkenfeld Multiple webbrowser.py bug fixes / improvements (2003-04-27) http://python.org/sf/728278 closed by birkenfeld python -c readlink()s and stat()s '-c' (2005-02-09) http://python.org/sf/1119423 closed by birkenfeld Bugfix for dircheck() in Objects/fileobject.c (2004-04-30) http://python.org/sf/944928 closed by birkenfeld tkinter hello world example bug (2005-08-31) http://python.org/sf/1277677 closed by birkenfeld Trivial typo in unicodedata._getcode (2005-06-03) http://python.org/sf/1213831 closed by loewis Cache lines in StreamReader.readlines (2005-08-24) http://python.org/sf/1268314 closed by loewis locale.getdefaultencoding: LANGUAGE not correctly parsed (2005-03-20) http://python.org/sf/1166938 closed by doko locale.getdefaultencoding: precedence of LANGUAGE / LANG (2005-03-20) http://python.org/sf/1166948 closed by doko locale: 'utf' is not a known encoding (2005-03-20) http://python.org/sf/1166957 closed by doko "Fatal Python error" from cStringIO's writelines (2005-09-22) http://python.org/sf/1298449 closed by mwh Unchecked return value in cStringIO (2005-09-22) http://python.org/sf/1298499 closed by mwh New / Reopened Bugs ___ Installation of waste by MacPython installer (2005-09-15) CLOSED http://python.org/sf/1291662 opened by Freek Dijkstra The _ssl build process for 2.3.5 is broken (2005-09-16) http://python.org/sf/1292634 opened by Robert Cheung doctest runner cannot handle non-ascii characters (2005-09-17) http://python.org/sf/1293741 opened by GRISEL Distutils writes keywords comma-separated (2005-09-17) http://python.org/sf/1294032 opened by Martijn Pieters Error in metaclass search order (2005-09-18) http://python.org/sf/1294232 opened by Pedro Werneck email.Parser.FeedParser leak (2005-09-18) CLOSED http://python.org/sf/1294453 opened by George Giannakopoulos Problems with /usr/lib64 builds. (2005-09-19) http://python.org/sf/1294959 opened by Sean Reifschneider termios.c in qnx4.25 (2005-09-19) http://python.org/sf/1295179 opened by kbob_ru cookielib undefined local variable error (2005-09-19) CLOSED http://python.org/sf/1295432 opened by Yusuke Shinyama expat symbols should be namespaced in pyexpat (2005-09-19) http://python.org/sf/1295808 opened by Trent Mick inspect.getsource() misses single line blocks. (2005-09-19) http://python.org/sf/1295909 opened by Ron Adam MemoryError in httplib (2005-09-20) http://python.org/sf/1296004 opened by Yue Zhang Python/C API Reference Manual, 7.2.1.1 Boolean Objects (2005-09-20) CLOSED http://python.org/sf/1296321 opened by Li Daobing expat crash python (2005-09-20) http://python.org/sf/1296433 opened by Mike Rozhnov Call by object reference sometimes call by value (2005-09-20) http://python.org/sf/1296434 opened by Alan G datetime.replace could take a dict (2005-09-20) http://python.org/sf/1296581 opened by Tom Lynn Incorrect return type for search() method (2005-09-21) http://python.org/sf/1297059 opened by Noah Spurrier hashable and mutable functions (2005-09-21) CLOSED http://python.org/sf/1297986 opened by ChristianJ shlex does not support unicode (2005-09-21) http://python.org/sf/1298120 opened by Wai Yip Tung _socket module not build under cygwin (2005-09-22
Re: [Python-Dev] Compressing MSI files: 2.4.2 candidate?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of "Martin v. Lowis" > Sent: Thursday, September 22, 2005 9:18 PM > To: Python-Dev > Subject: [Python-Dev] Compressing MSI files: 2.4.2 candidate? > > I just found that I can save somewhat more than 1MiB in the > MSI file by using LZX:21 instead of the standard MSZIP when > compressing the CAB file. A resulting package can be found at > > http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.2c1.msi > > Can people please test whether this installs just as well? Martin, The LZX:21-compressed package worked absolutely fine for me (Windows XP Professional Build 2600.xpsp_sp2_gdr). -- Vincent Wehren > > Is it ok to use this modified procedure for 2.4.2 final > (2.4.2c1 still uses MSZIP). > > 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/vwehren%40home.nl ___ 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
