Re: webbrowser.open always opens up Safari on Lion
On 2012-02-26 15:04 +0800, Cameron Simpson wrote: > On the suppostion that "the default browser" is actually multiple > settings, one for each of several URL (URI?) schemes, what do these two > shell commands do for you? From a shell prompt in a Terminal: > > open file://localhost/nonexistingfile > and > open http://www.python.org/ > > Do they both open Chome for you? The first one prints: The file /nonexistingfile does not exist. No browser is opened. The second one opened Chrome. Leo -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser.open always opens up Safari on Lion
On Sun, 26 Feb 2012 14:23:43 +0800, Leo wrote: > On 2012-02-26 11:36 +0800, Steven D'Aprano wrote: >> What part of this do you think is the bug, and why? What part of the >> behaviour actually experienced contradicts the documented behaviour of >> webbrowser.open()? >> >> http://docs.python.org/library/webbrowser.html > > If you have the default browser set to Chrome, it still opens up Safari. That would only be a bug if it occurs with http:// URLs. The documentation clearly says: Note that on some platforms, trying to open a filename using this function, may work and start the operating system’s associated program. However, this is neither supported nor portable. Since you are providing a file:// URL, then the behaviour is unspecified, and no, it is not a bug. Arguably it is a bug that file:// URLs work at all. However, I would guess that if you have a patch to fix this behaviour to something more reasonable (but what?) then it might be approved. Feel free to raise a ticket on the bug tracker. Personally, I'd put it down as a feature request rather than a bug. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser.open always opens up Safari on Lion
On 26Feb2012 14:23, Leo wrote: | On 2012-02-26 11:36 +0800, Steven D'Aprano wrote: | > What part of this do you think is the bug, and why? What part of the | > behaviour actually experienced contradicts the documented behaviour of | > webbrowser.open()? | > | > http://docs.python.org/library/webbrowser.html | | If you have the default browser set to Chrome, it still opens up Safari. On the suppostion that "the default browser" is actually multiple settings, one for each of several URL (URI?) schemes, what do these two shell commands do for you? From a shell prompt in a Terminal: open file://localhost/nonexistingfile and open http://www.python.org/ Do they both open Chome for you? -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ DRM doesn't inconvenience pirates ¿ indeed, over time it trains law-abiding users to become pirates out of sheer frustration. - Charles Stross -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser.open always opens up Safari on Lion
On 2012-02-26 11:36 +0800, Steven D'Aprano wrote: > What part of this do you think is the bug, and why? What part of the > behaviour actually experienced contradicts the documented behaviour of > webbrowser.open()? > > http://docs.python.org/library/webbrowser.html If you have the default browser set to Chrome, it still opens up Safari. Leo -- http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On 2/25/2012 9:49 PM, Devin Jeanpierre wrote: What this boils down to is to say that, basically by definition, the set of numbers representable in some finite number of binary digits is countable (just count up in binary value). But the whole of the real numbers are uncountable. The hard part is then accepting that some countable thing is 0% of an uncountable superset. I don't really know of any "proof" of that latter thing, it's something I've accepted axiomatically and then worked out backwards from there. Informally, if the infinity of counts were some non-zero fraction f of the reals, then there would, in some sense, be 1/f times a many reals as counts, so the count could be expanded to count 1/f reals for each real counted before, and the reals would be countable. But Cantor showed that the reals are not countable. But as you said, this is all irrelevant for computing. Since the number of finite strings is practically finite, so is the number of algorithms. And even a countable number of algorithms would be a fraction 0, for instance, of the uncountable predicate functions on 0, 1, 2, ... . So we do what we actually can that is of interest. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser.open always opens up Safari on Lion
On Sun, 26 Feb 2012 09:33:15 +0800, Leo wrote:
> Hello,
>
> On Lion and with its stock python version 2.7.1 r271:86832,
> webbrowser.open('file://localhost/nonexistingfile') always opens up
> Safari. Is this a bug?
What part of this do you think is the bug, and why? What part of the
behaviour actually experienced contradicts the documented behaviour of
webbrowser.open()?
http://docs.python.org/library/webbrowser.html
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser.open always opens up Safari on Lion
If Safari is your default browser, Python will open the address in Safari.
>From the Python docs:
webbrowser.open(url[, new=0[, autoraise=True]])
Display url using the default browser. If new is 0, the url is opened in
the same browser window if possible. If new is 1, a new browser window is
opened if possible. If new is 2, a new browser page (“tab”) is opened if
possible. If autoraise is True, the window is raised if possible (note that
under many window managers this will occur regardless of the setting of
this variable).
Note that on some platforms, trying to open a filename using this function,
may work and start the operating system’s associated program. However, this
is neither supported nor portable.
On Sat, Feb 25, 2012 at 8:33 PM, Leo wrote:
>
> Hello,
>
> On Lion and with its stock python version 2.7.1 r271:86832,
> webbrowser.open('file://localhost/nonexistingfile') always opens up
> Safari. Is this a bug?
>
> Leo
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On Sat, Feb 25, 2012 at 2:08 PM, Tim Wintle wrote: > > It seems to me that there are a great many real numbers that can be > > represented exactly by floating point numbers. The number 1 is an > > example. > > > > I suppose that if you divide that count by the infinite count of all > > real numbers, you could argue that the result is 0%. > > It's not just an argument - it's mathematically correct. ^ this The floating point numbers are a finite set. Any infinite set, even the rationals, is too big to have "many" floats relative to the whole, as in the percentage sense. In fact, any number we can reasonably deal with must have some finite representation, even if the decimal expansion has an infinite number of digits. We can work with pi, for example, because there are algorithms that can enumerate all the digits up to some precision. But we can't really work with a number for which no algorithm can enumerate the digits, and for which there are infinitely many digits. Most (in some sense involving infinities, which is to say, one that is not really intuitive) of the real numbers cannot in any way or form be represented in a finite amount of space, so most of them can't be worked on by computers. They only exist in any sense because it's convenient to pretend they exist for mathematical purposes, not for computational purposes. What this boils down to is to say that, basically by definition, the set of numbers representable in some finite number of binary digits is countable (just count up in binary value). But the whole of the real numbers are uncountable. The hard part is then accepting that some countable thing is 0% of an uncountable superset. I don't really know of any "proof" of that latter thing, it's something I've accepted axiomatically and then worked out backwards from there. But surely it's obvious, somehow, that the set of finite strings is tiny compared to the set of infinite strings? If we look at binary strings, representing numbers, the reals could be encoded as the union of the two, and by far most of them would be infinite. Anyway, all that aside, the real numbers are kind of dumb. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
webbrowser.open always opens up Safari on Lion
Hello,
On Lion and with its stock python version 2.7.1 r271:86832,
webbrowser.open('file://localhost/nonexistingfile') always opens up
Safari. Is this a bug?
Leo
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote: (2.0).hex() > '0x1.0p+1' (4.0).hex() > '0x1.0p+2' (1.5).hex() > '0x1.8p+0' (1.1).hex() > '0x1.1999ap+0' > jmf What's your point? I'm afraid my crystal ball is out of order and I have no idea whether you have a question or are just demonstrating your mastery of copy and paste from the Python interactive interpreter. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchronous downloading
>> I read through the python-dev archives and found the fundamental problem is >> no one maintains asnycore / asynchat. > > Well, actually I do/did. ah OK. I had read this comment from a few years back: "IIRC, there was a threat to remove asyncore because there were no maintainers, no one was fixing bugs, no one was improving it, and no one was really using it" > Point with asyncore/asynchat is that it's original design is so flawed > and simplicistic it doesn't allow actual customization without > breaking compatibility. Python3 uses the same API - was there not enough interest to improve it? Richard -- http://mail.python.org/mailman/listinfo/python-list
Udacity CS 101
Has anyone here looked at Udacity's open CS101 course (http://www.udacity.com/overview/Course/cs101) that started this week? The goal of the seven week course is to build a web crawler. So far, I'm not impressed with the speed or content of the course. I was wondering what anyone here may think of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
>>> (2.0).hex() '0x1.0p+1' >>> (4.0).hex() '0x1.0p+2' >>> (1.5).hex() '0x1.8p+0' >>> (1.1).hex() '0x1.1999ap+0' >>> jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On 2/25/2012 12:56 PM, Tobiah wrote: It seems to me that there are a great many real numbers that can be represented exactly by floating point numbers. The number 1 is an example. Binary floats can represent and integer and any fraction with a denominator of 2**n within certain ranges. For decimal floats, substitute 10**n or more exactly, 2**j * 5**k since if J < k, n / (2**j * 5**k) = (n * 2**(k-j)) / 10**k and similarly if j > k. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
On Feb 24, 7:50 pm, Steven D'Aprano wrote: > But it would also be rejected, and rightly so, as unnecessary complexity > for the int type. There are already Decimal and float infinities, just > use one of them. Sure there are float INFINITIES that work fine for ints and floats, but where is the consistency? INFINITY need not be a int or a float or a str, or whatever. All it need be is a an object who always returns itself as being larger in any comparison. > Or make your own, it's not difficult. INFINITY should be at the very least a constant of the math module. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
On Feb 25, 11:54 am, MRAB wrote: > [...] > That should be: > if maxlength is not None and len(string) <= maxlength: Using "imaginary" infinity values defiles the intuitive nature of your code. What is more intuitive? def confine_length(string, maxlength=INFINITY): if string.length < maxlength: do_something() def confine_length(string, maxlength=None): if maxlength is not None and len(string) <= maxlength: do_something() -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
On Feb 24, 6:35 pm, Mark Lawrence wrote: > I understand that a Python integer can run to infinity. Quite how the > illustrious rr manages to test for the length of a string that's already > used all of the memory on his system has baffled me, When did i ever say that i would need a string who's length is INFINITY? In fact, i don't. My example was just that, as SIMPLIFIED example of the problem that was the genesis of my question. In my "real world" problem, i don't expect the string to EVER be more than double digits in length. But as any good programmer knows, you never want to solve problems as globally as possible. I need to do comparisons on strings now, but maybe integers later, or who knows. INFINITY comparisons are useful in many places. > but I'm sure that > all the people who frequent this list with their Phds, MScs or whatever > will soon correct me. I don't believe you'd need a Phd to understand my problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On Sat, 2012-02-25 at 09:56 -0800, Tobiah wrote: > > For every floating point > > number there is a corresponding real number, but 0% of real numbers > > can be represented exactly by floating point numbers. > > It seems to me that there are a great many real numbers that can be > represented exactly by floating point numbers. The number 1 is an > example. > > I suppose that if you divide that count by the infinite count of all > real numbers, you could argue that the result is 0%. It's not just an argument - it's mathematically correct. The same can be said for ints representing the natural numbers, or positive integers. However, ints can represent 100% of integers within a specific range, where floats can't represent all real numbers for any range (except for the empty set) - because there's an infinate number of real numbers within any non-trivial range. Tim -- http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
> For every floating point > number there is a corresponding real number, but 0% of real numbers > can be represented exactly by floating point numbers. It seems to me that there are a great many real numbers that can be represented exactly by floating point numbers. The number 1 is an example. I suppose that if you divide that count by the infinite count of all real numbers, you could argue that the result is 0%. -- http://mail.python.org/mailman/listinfo/python-list
[RELEASED] Release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're pleased to announce the immediate availability of release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times and denials of service. [1] Python dict and set types use hash tables to provide amortized constant time operations. Hash tables require a well-distributed hash function to spread data evenly across the hash table. The security issue is that an attacker could compute thousands of keys with colliding hashes; this causes quadratic algorithmic complexity when the hash table is constructed. To alleviate the problem, the new releases add randomization to the hashing of Python's string types (bytes/str in Python 3 and str/unicode in Python 2), datetime.date, and datetime.datetime. This prevents an attacker from computing colliding keys of these types without access to the Python process. Hash randomization causes the iteration order of dicts and sets to be unpredictable and differ across Python runs. Python has never guaranteed iteration order of keys in a dict or set, and applications are advised to never rely on it. Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to enable it. The -R commandline option can be passed to the python executable. It can also be enabled by setting an environmental variable PYTHONHASHSEED to "random". (Other values are accepted, too; pass -h to python for complete description.) More details about the issue and the patch can be found in the oCERT advisory [1] and the Python bug tracker [2]. These releases are releases candidates and thus not recommended for production use. Please test your applications and libraries with them, and report any bugs you encounter. We are especially interested in any buggy behavior observed using hash randomization. Excepting major calamity, final versions should appear after several weeks. Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ Please test these candidates and report bugs to http://bugs.python.org/ With regards, The Python release team Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1) [1] http://www.ocert.org/advisories/ocert-2011-003.html [2] http://bugs.python.org/issue13703 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
On 25/02/2012 08:18, Wolfgang Meiners wrote: Am 24.02.12 14:37, schrieb Rick Johnson: I get sick and tired of doing this!!! if maxlength == UNLIMITED: allow_passage() elif len(string)> maxlength: deny_passage() What Python needs is some constant that can be compared to ANY numeric type and that constant will ALWAYS be larger! If there is no limit for len(string), why not simply use # get_limit() returns None if there is no limit maxlength = get_limit() if maxlength and (len(string)<= maxlength): allow_passage() else: deny_passage() That should be: if maxlength is not None and len(string) <= maxlength: -- http://mail.python.org/mailman/listinfo/python-list
importing python modules from java
Hello,
I have written a c++ library which embeds python functions as described in
http://docs.python.org/extending/embedding.html. Everything works fine, I can
import and use modules such as numpy by calling PyImport_ImportModule(...).
Now I wrapped this c++ library for java using SWIG. However, when running
inside this wrapper, an attempt to import numpy fails:
PyObject *numpy_module = PyImport_ImportModule("numpy");
returns NULL for numpy_module.
I guess I have a similar problem as described in
http://www.ibm.com/developerworks/aix/library/au-integratepython.html. It seems
that since python 2.3 it is complicated to nest a module import in an embedded
python environment. I don't understand the details of their explanations and I
cannot use their solution to simulate the java executable, because the library
is supposed to be part of an existing java framework.
Is there a possibility to import numpy from python2.6, embedded in a c++
library, which is dynamically loaded from java? I am working on Debian linux,
if this matters.
Regards
Jeff
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
25.02.12 02:37, MRAB написав(ла):
We already have arbitrarily long ints, so there could be a special
infinite int singleton (actually, 2 of them, one positive, the other
negative).
float('inf') and float('-inf').
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python packaging usabilty (distutils) - automatic downloading required packages
XLiIV, 25.02.2012 15:47: > There is many packaging solutions for python. > I was confused about that but it's nothing. I had to pick one of them. > I picked distutils because it's part of standard python since 3.3, am > i right? Distutils has been part of Python's stdlib for ages. > My goal is to write setup.py with this feature: 'download required > package if not installed already, like sqlalchemy'. > How can I achieve that with DISTUTILS? > I found out that is not possible, seriously? I can't believe that. > It's basic function, I think. > Do I really switch to setuptools? No, use "distribute" instead. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Python packaging usabilty (distutils) - automatic downloading required packages
There is many packaging solutions for python. I was confused about that but it's nothing. I had to pick one of them. I picked distutils because it's part of standard python since 3.3, am i right? My goal is to write setup.py with this feature: 'download required package if not installed already, like sqlalchemy'. How can I achieve that with DISTUTILS? I found out that is not possible, seriously? I can't believe that. It's basic function, I think. Do I really switch to setuptools? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
Am 24.02.12 14:37, schrieb Rick Johnson: > I get sick and tired of doing this!!! > > if maxlength == UNLIMITED: > allow_passage() > elif len(string) > maxlength: > deny_passage() > > What Python needs is some constant that can be compared to ANY numeric > type and that constant will ALWAYS be larger! > > > If there is no limit for len(string), why not simply use # get_limit() returns None if there is no limit maxlength = get_limit() if maxlength and (len(string) <= maxlength): allow_passage() else: deny_passage() Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
