Re: [Python-Dev] Grammar for plus and minus unary ops
Jared Grubb wrote: I'm not a EBNF expert, but it seems that we could modify the grammar to be more restrictive so the above code would not be silently valid. E.g., ++5 and 1+++5 and 1+-+5 are syntax errors, but still keep 1++5, 1+-5, 1-+5 as valid. (Although, '~' throws in a kink... should '~-5' be legal? Seems so...) So you want something like u_expr :: = power | - xyzzy_expr | + xyzzy_expr | \~ u_expr xyzzy_expr :: = power | \~ u_expr Such that: 5 # valid u_expr +5 # valid u_expr -5 # valid u_expr ~5 # valid u_expr ~~5 # valid u_expr ~+5 # valid u_expr +~5 # valid u_expr ~-5 # valid u_expr -~5 # valid u_expr +~-5# valid u_expr ++5 # not valid u_expr +-5 # not valid u_expr -+5 # not valid u_expr --5 # not valid u_expr While, I'm not a python developer, (just a python user) that sounds reasonable to me, as long as this does not silently change the meaning of any expression, but only noisily breaks programs, and that the broken constructs are not used frequently. Can anybody come up with any expressions that would silently change in meaning if the above were applied? Obviously a sane name would need to be chosen to replace xyzzy_expr. ___ 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] [Pydotorg] Should we help pythonmac.org?
Jesse Noller [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen [EMAIL PROTECTED] wrote: My understanding is that if there is a system Python, you shouldn't change it. Ever. Huge, big, honkin' +1 from me on that. Besides, for a system Python, you want your distribution to manage packages, not setuptools, otherwise you confuse -- and probably break -- your system. I find this discussion fascinating. I install new packages into my system Python all the time, with /usr/bin/python setup.py install, and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, roman, setuptools, and SSL installed in the Leopard machine I'm writing from. They don't wind up in /System/Library/.../site-packages/, they wind up in /Library/Python/2.5/site-packages/, which is sort of the right place, from an Apple point of view. I do this on lots of Macs -- I've got a regular posse of them at work. And I've never had any problems with it. I agree that there are some things I'd be very wary of installing into the system Python, like PyObjC, and Zope. Usually, I don't install anything which appears to already be there. Bill Bill is correct - using /usr/bin/python does install packages to /Library/... - this is sort of the right place because it still installs it to a system path, where it can side-effect other users, but it is a mostly correct way for Apple framework installs. /Library is system-wide, yes, but not system-reserved. /System/Library/ is system-wide and system reserved. Just like on most distros (LFS and some older distros excluded): /usr/ is system-wide and system-reserved. /usr/local/ is sytem-wide, but not system-reserved. Computer admins are supposed to install into /Library/ or /usr/local/. The only possible problem of installing new Python modules into /Library/ is if any system Python scripts that depend on exact versions of libraries shipped in /System/Library/, but were not crafted as to ignore /Library/. That can be problematic, and arguablly a bug in the script, but Apple does not tend to fix those bugs that quickly. (OS bugs is one area where Apple's traditional secrecy is a bad thing. More transparency in bug fixing can only be an improvement.) ___ 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] UCS2/UCS4 default
Martin v. Löwis martin at v.loewis.de writes: Wrong term - code units and code points are equivalent in UTF-16 and UTF-32. What you're looking for is unicode scalar values. How so? Section 2.5, UTF-16 says code points in the supplementary planes, in the range U+1..U+10, are represented as pairs of 16-bit code units. So clearly, code points in Unicode range from U+..U+10, independent of encoding form. In UTF-16, code units range from 0..65535. OTOH, unicode scalar value is nearly synonymous to code point: D76 Unicode Scalar Value. Any Unicode code point except high-surrogate and low-surrogate code points. So codepoint in Terry's message was the right term. No Terry did definitely mean Unicode scalar values. He was describing the pure but impractical len() that would count a surrogate pair as 1, not 2, even in the 32-bit builds. For what it is worth: Code point: a number between 0 and 1114111. Scalar Value: a code point, except the surrogate code points. Code unit: The basic unit of the encoding. One code unit is always sufficient to encode some Unicode Scalar values. However, other Unicode scalar values may require multiple Code units. Note that a scalar value is a code point. A code point may or may not be a scalar value. Practical len() returns the number of code units of the internal storage format. Pure len() allegedly would return the number of Unicode scalar values (obviously a surrogate pair would be considered a single Unicode scalar value). Please keep in mind that encodings encode Unicode scalar values. Thus a utf-8 code unit sequence (or UTF-32 code unit) that would give a code point in the surrogate sections is technically in error. (Although python would do well to ignore this restriction as there may be valid reasons to have a utf-8 sequence that is not a valid encoded Unicode text sequence) ___ 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] Invitation to try out open source code review tool
Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Personally, I would consider the following sufficient: 1) people who have authenticated themselves against the underlying VCS (i.e. project members) may post public comments and comment on other comments Tell me how to authenticate against a SVN project using HTTP only. Hmm... Is there a good reason not to just migrate over to OpenID? For one thing, surely an OpenID provider could exist that just authenticates a username against an SVN account. Then many people already have a Yahoo account or AOL screenname. On the downside, the OpenID system will likely not be terribly effective at avoiding spam in the long run, as spammers register accounts at providers (especially those without or with weak Captchas). On the otherhand, there are already reports of Spammers mass signing-up for Google accounts, so it may not be that different in the long run anyway. ___ 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] Typo.pl scan of Python 2.5 source code
Neal Norwitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I ignored these as I'm not certain all the platforms we run on accept free(NULL). That sounds like exactly what the autotools are designed for. You simply use free(), and have autoconf check for support of free(NULL). If free(NULL) is broken then a macro is defined: #define free(p) (p==NULL)||free(p) Or something like that. Note that this does not clutter up the main program any. In fact it simplifies it. It also potentially speeds up platforms with a working free, without any negative speed implications for other platforms. The only downside is a slight, presumably negligible, increase in build time. ___ 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 2.4, VS 2005 Profile Guided Optmization
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Joe Smith wrote: Microsoft as a general rule, does not go after people distributing products that Microsoft has labeled free, even after Microsoft no longer distributes that product. But if the licence agreement technically forbids redistribution, it doesn't seem like a good idea to rely on Microsoft turning a blind eye to that. I agree, although it seems very unlikely Microsoft would bother as they are busy enough the the pirating of the for-cost software. I was a little surprised that they did not allow verbatim duplicates of that software, expecially as it has the feel of freeware, or even shareware (the commecial versions have additional features). I would actually not be surprised if somebody could convince Microsoft to allow them to distribute these versions even after Microsoft no longer supports them. That would be the ideal situation. ___ 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 2.4, VS 2005 Profile Guided Optmization
Joe Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Neil Hodgson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Trent Nelson: I ended up playing around with Profile Guided Optimization, running ``python.exe pystones.py'' to collect call-graph data after python.exe/Python24.dll had been instrumented, then recompiling with the optimizations fed back in. It'd be an idea to build a larger body of Python code to run the profiling pass on so it doesn't just optimize the sort of code in pystone which is not very representative. Could run the test suite as it would have good coverage but would hit exceptional cases too heavily. Other compilers (Intel?) support profile directed optimization so would also benefit from such a body of code. GCC suppost profiling optimized code. Err... That was supposed to say supports profile-optimized code. The rest of the message was indeed about Profile Guided Optimization in gcc. ___ 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 2.4, VS 2005 Profile Guided Optmization
James Y Knight [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Jul 23, 2006, at 4:41 PM, Giovanni Bajo wrote: I think Martin decided to keep VC71 (Visual Studio .NET 2003) for another release cycle. Given the impressive results of VC8 with PGO, and the fact that Visual Studio Express 2005 is free forever, I would hope as well for the decision to be reconsidered. Wasn't there a Free Forever 2003 edition too, which has since completely disappeared? Why do you think that MS won't stop distributing the Free Forever VS 2005 once VS 2005+1 comes out, the same way they did the 2003 one? I am not aware of any full free ofeering based on 2003. There were ways to get the command line tools, but the GUI's were not available. Most of the freely available command line utilities are still available from microsoft if you find the correct page. I will note that according to the FAQ, Profile Guided Optimizations will not be available with Express. Because the compiler is the same, this means the tools to generate a profile are all that is missing. Express should still be able to build using the optimized profile. Microsoft as a general rule, does not go after people distributing products that Microsoft has labeled free, even after Microsoft no longer distributes that product. So the express editions will continue to be available long into the future if 2005+1 does not have a free version. (The logic behind this is that Microsoft would have a hard time explaining to a jury how somebody can pirate software that is available at no cost.) ___ 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 2.4, VS 2005 Profile Guided Optmization
Neil Hodgson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Trent Nelson: I ended up playing around with Profile Guided Optimization, running ``python.exe pystones.py'' to collect call-graph data after python.exe/Python24.dll had been instrumented, then recompiling with the optimizations fed back in. It'd be an idea to build a larger body of Python code to run the profiling pass on so it doesn't just optimize the sort of code in pystone which is not very representative. Could run the test suite as it would have good coverage but would hit exceptional cases too heavily. Other compilers (Intel?) support profile directed optimization so would also benefit from such a body of code. GCC suppost profiling optimized code. One caveat is that the profile-enabled builds ause a GPL'd library. Not a problem for Python right now as it is GPL-compatible, but a caveat non-the-less. That does not apply to the final optimized app. Anyway the flags used are: -fprofile-generate and -fprofile-use. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
Edward Loper [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Talin wrote:
Braces can be escaped using a backslash:
My name is {0} :-\{\}.format('Fred')
Which would produce:
My name is Fred :-{}
Do backslashes also need to be backslashed then? If not, then what is
the translation of this:?
r'abc\{%s\}' % 'x'
I guess the only sensible translation if backslashes aren't backslashed
would be:
.format('x')
But the parsing of that format string seems fairly unintuitive to me.
If backslashes do need to be backslashed, then that fact needs to be
mentioned.
AFAICT there would be no way to use raw strings with that method. That
method
would be using the escape sequence \{ to indicate a bracket. Raw strings
cannot have escape sequences.
Additional backslashes are added to raw strings to remove anything that
resembles an escape sequence.
So either an additional layer of escaping is required (like with regex'es)
or .format() would
simply not be usable with raw strings.
The problem of having an additional level of escaping is very shown with
regexes. A simgle slash
as the end value is either or r\\.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Talin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Abstract
This PEP proposes a change to the way that function arguments are
assigned to named parameter slots. In particular, it enables the
declaration of keyword-only arguments: arguments that can only
be supplied by keyword and which will never be automatically
filled in by a positional argument.
Rationale
The current Python function-calling paradigm allows arguments to
be specified either by position or by keyword. An argument can be
filled in either explicitly by name, or implicitly by position.
There are often cases where it is desirable for a function to take
a variable number of arguments. The Python language supports this
using the 'varargs' syntax ('*name'), which specifies that any
'left over' arguments be passed into the varargs parameter as a
tuple.
One limitation on this is that currently, all of the regular
argument slots must be filled before the vararg slot can be.
This is not always desirable. One can easily envision a function
which takes a variable number of arguments, but also takes one
or more 'options' in the form of keyword arguments. Currently,
the only way to do this is to define both a varargs argument,
and a 'keywords' argument (**kwargs), and then manually extract
the desired keywords from the dictionary.
First of all, let me remark that The current python symantics almost
perfectly
match those of VB6. Sure there is a little bit of syntax differences, but
overall
they are approximately equivlent. This is actually a good thing
The one area thing that VB6 allows that python does not is optional
arguments
without a default value. However, what really happens is that the compiler
assigns a default
value, so it really is only a tiny difference.
The main proposal here adds an aditional feature, and thus will break th
matching of VB6,
but not in a negative way, as VB6 could benefit from the same extention. So
I would be +1.
However, I'm not sure what the use case is for keyword only arguments on
functions
that do *not* accept a variable number of arguments. Could you please
provide an example use case?
___
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] Dropping __init__.py requirement for subpackages
Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] (Context: There's a large crowd with pitchforks and other sharp pointy farm implements just outside the door of my office at Google. They are making an unbelievable racket. It appears they are Google engineers who have been bitten by a misfeature of Python, and they won't let me go home before I have posted this message.) One particular egregious problem is that *subpackage* are subject to the same rule. It so happens that there is essentially only one top-level package in the Google code base, and it already has an __init__.py file. But developers create new subpackages at a frightening rate, and forgetting to do touch __init__.py has caused many hours of lost work, not to mention injuries due to heads banging against walls. It seems to me that the right way to fix this is to simply make a small change to the error message. On a failed import, have the code check if there is a directory that would have been the requested package if it had contained an __init__ module. If there is then append a message like You might be missing an __init__.py file. It might also be good to check that the directory actually contained python modules. ___ 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] conditional expressions - add parens?
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jeremy Hylton wrote: Perhaps the solution is to require parens around all expressions, a simple consistent rule. I actually designed a language with that feature once. It was an exercise in minimality, with hardly anything built-in -- all the arithmetic operators, etc. were defined in the language. A result was that there was no built-in notion of precedence, and my solution was to require parentheses around every infix operation. So instead of dsq = b * b - 4 * a * c you would have had to write dsq = ((b * b) - ((4 * a) * c)) I never got an implementation working well enough to find out how much of a disaster this would have been to use, though. :-) Well the original was almost certainly a tongue-in-cheek reference to LISP. LISP was a disaster to use, so I doubt your language would have been any worse. The way one identifies a lisp programmer is to find the person whose paren keys have worn competely off their keyboard. :D ___ 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] conditional expressions - add parens?
Steve Holden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Jim Jewett wrote:
I think that adding parentheses would help, by at least signalling that
the logic is longer than just the next (single) expression.
level = (0 if absolute_import in self.futures else -1)
Contrast with the bleeding obvious:
level = 0
if absolute_import in self.futures:
level = -1
or even, if a certain obscurity is desirable:
level = - (absolute_import in self.futures)
Wait a second.
I may be just a user but if the above is correct then that syntax needs to
die!
There is no logical reason for XX if YY else ZZ to be roughly equivlent
to:
if (YY) then {ZZ} else {XX} , but AFAICT that is pretty much the way you
expanded that.
I hope I misunderstood, or that there was a typo in a post.
___
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] bdist_* to stdlib?
Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In private email, Phillip Eby suggested to add these things to the 2.5. standard library: bdist_deb, bdist_msi, and friends He explained them as follows: bdist_deb makes .deb files (packages for Debian-based Linux distros, like Ubuntu). bdist_msi makes .msi installers for Windows (it's by Martin v. Loewis). Marc Lemburg proposed on the distutils-sig that these and various other implemented bdist_* formats (other than bdist_egg) be included in the next Python release, and there was no opposition there that I recall. I don't like the idea of bdist_deb very much. The idea behind the debian packaging system is that unlike with RPM and Windows, package management should be clean. Windows and RPM are known for major dependency problems, letting packages damage each other, having packages that do not uninstall cleanly (i.e. packages that leave junk all over the place) and generally messing the sytem up quite baddly over time, so that the OS is usually removed and re-installed periodically.) The Debian style system attempts to overcome these deficiencies, and generally does a decent job with it. The problem is that this can really only work if packages are well maintained, and adhere to a set of policies that help to further mitigate these problems. Even with all of that, packages from one debian based distribution may well cause problems with a different one. For that reason it is quite rare to see .debs distributed by parties other than those directly involved with a Debian-based distribution, and even then they are normally targeted specifically at one distibution. Making it easy to generate .debs of python modules will likely result in a noticable increase in the number of .debs that do not target a specific distribution and/or do not follow the policies of that distribution. So basically what I am saying is that such a system has a pretty good chance of resulting in debs that mess-up users systems, and that is not good. I'm not saying don't do it, but if it would be included in the standard library, procede with caution! ___ 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] SourceForge Download Page, Subversion Home Page
Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You may be aware that Tim Parkin's work on our next-generation web presence has borne fruit in the shape of beta.python.org. While there's still a lot to be done Tim has given us a great start by creating a framework that makes it rather easier to manage content. For the record, I'm just a user of the language. However, I tend to prefer the current site design over the new one. But I also felt the same way when the Mozilla.org site was updated to be more 'friendly' (quite a while ago), and have learned to live with it, so it is not a major problem. There's the further issue that the entire HTML body of http://svn.python.org/ currently reads !-- not sure what to put here -- It would seem like the logical place to have pointers to Subversion software (downloads, documentation, operating instructions) together with an *annotated* summary of http://svn.python.org/projects/ and links back to the main developer site at the very least. I'm not even sure where that web content is under SVN control at the moment. Also If there is any sort of webcvs software running, it may be ice to link to it from that page. ___ 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
