Re: Python 3.4.4 Install
Steven D'Aprano pearwood.info> writes:
>
> On Sun, 10 Jan 2016 09:25 am, Colin J. Williams wrote:
>
> > The reponse is not understood.
> >
> > *** Python 3.4.4rc1 (v3.4.4rc1:04f3f725896c, Dec 6 2015, 17:06:10) [MSC
> > v.1600 64 bit (AMD64)] on win32. ***
> >>>> File "C:\Users\Adm\AppData\Roaming\PyScripter\python_init.py", line 1
> > Öü:Vt‡Ö{ZðN)’ƒ2%hóýL"®ÁwÇ,”¿Æ¾J
> > ^
> > SyntaxError: invalid syntax
>
> That doesn't look anything like Python code to me. It looks like you have
> corrupted files. Who knows how they have been corrupted. Try re-installing
> Pyscripter, or revert from backup. Also, you should make sure you scan your
> system for viruses (possibly you have a randsomware virus encrypting files
> behind your back) and do a disk check in case the disk is dying.
>
I am now trying o install the binary version, 64 bit, of Python 3.4.4 from
Python.org. I get the message:
Python 3.4.4 (64 bit)
There is a problem with the Windows [10] Installer Package. A program
required for this install to complete could not be run. Contact your
support personnel or package vendor.
Colin W.
--
https://mail.python.org/mailman/listinfo/python-list
Re: a 100-line indentation-based preprocessor for HTML
On 27-Nov-09 22:04 PM, Steve Howell wrote: Python has this really neat idea called indentation-based syntax, and there are folks that have caught on to this idea in the HTML community. AFAIK the most popular indentation-based solution for generating HTML is a tool called HAML, which actually is written in Ruby. I have been poking around with the HAML concepts in Python, with the specific goal of integrating with Django. But before releasing that, I thought it would be useful to post code that distills the basic concept with no assumptions about your target renderer. I hope it also serves as a good example of what you can do in exactly 100 lines of Python code. Here is what it does... You can use indentation syntax for HTML tags like table. From this... table tr td Left td Center td Right ...you get this: ... [snip] This is a neat idea but would a two character indentation not be enough? Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: semantics of ** (unexpected/inconsistent?)
On 29-Nov-09 19:50 PM, Chris Rebert wrote: On Sun, Nov 29, 2009 at 4:39 PM, Esmail wrote: Ok, this is somewhat unexpected: Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. -3**2 -9 x = -3 x**2 9 I would have expected the same result in both cases. Initially I would have expected -3**2 to yield 9, but I can accept that ** binds tighter than the unary -, but shouldn't the results be consistent regardless if I use a literal or a variable? _No_, because using the variable evaluates "-3" as a unit separately by itself, before the exponentiation ever occurs; it's the same as the difference between (-3)**2 and -3**2. Python is not a concatenative programming language[*]; you can't directly textually replace a variable with its value and expect to get the same result from an expression. For instance, in this case, you need to add the parentheses. Cheers, Chris -- http://blog.rebertia.com [*] http://en.wikipedia.org/wiki/Concatenative_language See the Operator Order of Precedence: http://docs.python.org/reference/expressions.html#summary Parentheses permit the user to vary the precedence. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: When will Python 3 be fully deployed
On 06-Dec-09 13:25 PM, Luis M. González wrote: On Dec 6, 3:21 pm, vsoler wrote: I recently read that many libraries, including Numpy have not been ported to Python 3. When do you think that Python 3 will be fully deployed? Should I stick, so far, to Python 2.6? Regards Vicente Soler You'll have some answers here: http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/ 2.7 is now available. Work is going on numpy with Python 3.0 Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Perl to Python conversion
On 09-Dec-09 15:33 PM, Martin Schöön wrote: First off: I am new here and this is my first post after lurking for quite some time. Second off: I don't know much Python---yet. Problem: I have come across a small open source application that I find quite useful. It does have one major flaw though. Its output is in imperial units. Converting isn't a big deal for occasional use but if I start to use this stuff on a regular basis... So I down-loaded the source code and found this thing is written in Perl. Should I learn enough Perl to add the conversion? Probably but this may be a nice excuse to get my Python education going and if I do I might as well re-do the user interface. If I do re-write this thing in Python I might need to learn both Perl and Python... Hence, are there any Perl to Python converters? So far I have only found bridgekeeper which really is (was?) consultancy. Apart from that I only find people recommending a manual re-write. Any thoughts/recommendations? TIA, /Martin Martin, If you convert the Perl, you continue the other fellow's errors. If you do it yourself, you'll be able to make your own - there should be fewer of them. Google: unit conversion python you'll have lots of offers. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Seek support for new slice syntax PEP.
On 14-Dec-09 13:03 PM, Dave wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python user. The slice notation would
require one ":" between the brackets to differentiate it from a list,
which is similar to the set notation requirement that disambiguates it
from a dictionary.
Several times now I've wanted python slice notation. Perhaps I'll
write a Python Enhancement Proposal. I stored slices of vector array
entries to add
edge = 4
indexes = []
n = edge
nn = n**2
for i in range(edge):
indexes.extend([
slice(i*n,(i+1)*n,1), # rows
slice(i,nn,n), # cols
])
row_slices = indexes[0::2]
col_slices = indexes[1::2]
slash = slice(n-1,n*(n-1)+1,n-1)
backslash = slice(0,nn,n+1)
Which could have been written in a manner completely consistent with
other python shorthand notations and for which python "cannot
possibly" use the notation for some other purpose,
edge = 4
indexes = []
n = edge
nn = n**2
for i in range(edge):
indexes.extend([
[i*n: (i+1)*n] # rows
[i: nn: n], # cols
])
row_slices = indexes[0::2]
col_slices = indexes[1::2]
slash = [n-1: n*(n-1)+1: n-1]
backslash = [0: nn: n+1]
Yes, we know that PEP 3003 applies but I see no harm in discussing
possible enhancements.
The existing slice seems a little different from what you are proposing:
An object usually containing a portion of a sequence. A slice is created
using the subscript notation, [] with colons between numbers when
several are given, such as in variable_name[1:3:5].
or:
Slice objects
Slice objects are used to represent slices when extended slice syntax is
used. This is a slice using two colons, or multiple slices or ellipses
separated by commas, e.g., a[i:j:step], a[i:j, k:l], or a[..., i:j].
They are also created by the built-in slice() function.
If your scheme flies, would it be practicable to use the same syntax
as a range generator?
range(i, j, k) => i:j:k
so range(10, 2) => :10:2
i.e. we could write for i in :10:2:
or the more common:
range(10) => :10
Colin W.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Seek support for new slice syntax PEP.
On 16-Dec-09 19:23 PM, Gregory Ewing wrote: Terry Reedy wrote: So it would be MUCH more useful if that notation created a range object. for i in [1:n]: ... So I would oppose the slice proposal in favor of a range proposal. Another possibility would be to unify range and slice objects so that they're actually the same thing. Then the same notation could be used for both purposes. This would be good if the increment could also be handled. Terry Reedy suggested:- for i in [1:n]: ... Are the brackets really needed? Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Seek support for new slice syntax PEP.
On 17-Dec-09 20:00 PM, Nobody wrote: On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote: Many more people uses range objects (xrange in 2.x). A range object has the same info as a slice object *plus* it is iterable. This isn't quite true, as a range cannot have a stop value of None, i.e. you can't represent [n:] or [:] etc as a range. Similarly for using negative stop values for indices relative to the end of the sequence being sliced. Also, aside from the semantics of slice objects themselves, slice notation isn't limited to a single slice object; it can also return a tuple of slices and values, e.g.: > numpy.s_[1::2,...,3,4:5:6] (slice(1, None, 2), Ellipsis, 3, slice(4, 5, 6)) For a single slice, enumerating over a slice with an unspecified stop value would be equivalent to itertools.count(). Negative stop values won't work. For a multi-dimensional slice, with everything specified, you would probably want to iterate over the cartesian product (i.e. N nested loops for an N-dimensional slice). But this won't work if anything other than the outermost loop has an unspecified stop value, or if you use an ellipsis within a slice. Oh, and being able to slice a slice could be quite useful, i.e.: [10:90:10][2::2] == [30:90:20] cf: > numpy.arange(100)[10:90:10][2::2] array([30, 50, 70]) > numpy.arange(100)[30:90:20] array([30, 50, 70]) You don't say, but seem to imply that the slice components include None. Section 5.3.3 of the Python doc for 2.6.4 has The lower and upper bound expressions, if present, must evaluate to plain integers; defaults are zero and the sys.maxint, respectively. If either bound is negative, the sequence’s length is added to it. The slicing now selects all items with index k such that i <= k < j where i and j are the specified lower and upper bounds. This may be an empty sequence. It is not an error if i or j lie outside the range of valid indexes (such items don’t exist so they aren’t selected). Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Seek support for new slice syntax PEP.
On 17-Dec-09 20:00 PM, Nobody wrote: On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote: Many more people uses range objects (xrange in 2.x). A range object has the same info as a slice object *plus* it is iterable. This isn't quite true, as a range cannot have a stop value of None, i.e. you can't represent [n:] or [:] etc as a range. Similarly for using negative stop values for indices relative to the end of the sequence being sliced. Also, aside from the semantics of slice objects themselves, slice notation isn't limited to a single slice object; it can also return a tuple of slices and values, e.g.: > numpy.s_[1::2,...,3,4:5:6] (slice(1, None, 2), Ellipsis, 3, slice(4, 5, 6)) For a single slice, enumerating over a slice with an unspecified stop value would be equivalent to itertools.count(). Negative stop values won't work. For a multi-dimensional slice, with everything specified, you would probably want to iterate over the cartesian product (i.e. N nested loops for an N-dimensional slice). But this won't work if anything other than the outermost loop has an unspecified stop value, or if you use an ellipsis within a slice. Oh, and being able to slice a slice could be quite useful, i.e.: [10:90:10][2::2] == [30:90:20] cf: > numpy.arange(100)[10:90:10][2::2] array([30, 50, 70]) > numpy.arange(100)[30:90:20] array([30, 50, 70]) You don't say, but seem to imply that the slice components include None. Section 5.3.3 of the Python doc for 2.6.4 has The lower and upper bound expressions, if present, must evaluate to plain integers; defaults are zero and the sys.maxint, respectively. If either bound is negative, the sequence’s length is added to it. The slicing now selects all items with index k such that i <= k < j where i and j are the specified lower and upper bounds. This may be an empty sequence. It is not an error if i or j lie outside the range of valid indexes (such items don’t exist so they aren’t selected). Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Seek support for new slice syntax PEP.
On 18-Dec-09 23:16 PM, Nobody wrote: On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote: You don't say, but seem to imply that the slice components include None. That's how missing components are implemented at the language level: > class foo: = def __getitem__(self, s): = return s = > x = foo() > x[::] slice(None, None, None) > x[1::2] slice(1, None, 2) The defaults of zero, sys.maxint and one apply to built-in types, but nothing forces user-defined types to behave this way. Or maybe I misunderstood your point. No, it seems that the implementation is a little different from the doc. You are right: *** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32. *** >>> a= range(10) >>> a[2:8:2] [2, 4, 6] >>> a[2::2] [2, 4, 6, 8] >>> a[2:None:2] [2, 4, 6, 8] >>> I had expected the last to be rejected, but it fits with the overall philosophy. Colin W -- http://mail.python.org/mailman/listinfo/python-list
Re: r"string" vs R"string
On 17-Jan-10 02:16 AM, Terry Reedy wrote: On 1/17/2010 1:55 AM, Brendan Miller wrote: Is there any difference whatsoever between a raw string beginning with the captical R or one with the lower case r e.g. r"string" vs R"string"? No. Nor is there and difference between the strings created with raw literals and cooked literals. "cooked" literal ?? -- http://mail.python.org/mailman/listinfo/python-list
Re: r"string" vs R"string
On 17-Jan-10 18:27 PM, Steven D'Aprano wrote: On Sun, 17 Jan 2010 11:13:48 -0500, Roy Smith wrote: In article, "Colin W." wrote: On 17-Jan-10 02:16 AM, Terry Reedy wrote: On 1/17/2010 1:55 AM, Brendan Miller wrote: Is there any difference whatsoever between a raw string beginning with the captical R or one with the lower case r e.g. r"string" vs R"string"? No. Nor is there and difference between the strings created with raw literals and cooked literals. "cooked" literal ?? I've never seen it referred to this way in the Python literature, but "cooked" is a well-known term meaning, "not raw". The usage goes back decades. I think the use of "cooked" meaning "not raw" goes back a little bit more than decades. The verb "to cook" dates from the late 14th century, and the adjective form "cooked" would follow soon after. The use of "cooked" to mean manipulated (as in "cooking the books") comes from the 1630s. Extending it to strings (as in raw versus cooked strings) is an obvious extension. Yes, I should have cottoned on, but perhaps "... between the strings, raw and other." would have conveyed the idea. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQT4 user group
Diez B. Roggisch wrote: Chris wrote: Hi! I'm starting to learn and use PyQT4 at work. Is there a good user group or forum out there that I should know about? The PyQt Mailinglist. Diez I find the Gmane server, which delivers items from the PyQt Mailing List, easier to use. It threads the messages. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why 'import module' will not import module.py but the directory module?
Robert Kern wrote: On 2009-10-31 19:16 PM, Peng Yu wrote: On Sat, Oct 31, 2009 at 7:02 PM, Robert Kern wrote: On 2009-10-31 18:51 PM, Peng Yu wrote: If I have both the directory 'module' and the file 'module.py' in a directory in $PYTHONPATH, python will import 'module' rather than 'module.py'. I'm wondering what is the design rationale of setting higher priorities to directories. Is there a way to reverse the priority? You mean that you have a package "module/"? With an __init__.py? Plain directories that aren't packages shouldn't be imported by Python. Yes. I mean a pakcage 'module/' with an __init__.py. No, you can't reverse the priority between packages and modules. I'm not sure why that would help you. The package would then be inaccessible if you did. If it's inaccessible, then why have it at all? Why the package 'module' has to be inaccessible? I can 'import module.part1' to access the component of the package. No, it wouldn't. It's a moot point because Python picks the package first, but if it did pick modules before packages, then sys.modules['module'] would point to the module from module.py and not module/__init__.py . "import module.part1" first executes "import module", then looks in there to determine who to resolve "module.part1". Since sys.modules['module'] is a regular module and not the package, it wouldn't find module/part1.py . Doesn't it make sense to avoid the use of names like module or package, even though they are permitted. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem combining Scientific (leastSquaresFit) and scipy (odeint)
Harold Fellermann wrote: Hi, I need to perform leastSquaresFit of a model that is given by a differential equation for which there seems to be no analytic solution. So, I am trying to solve the ODE numerically (using scipy.integrate.odeint) within the function I provide to leastSquaresFit as a model: def func(L, t, a, k) : return -k * L * (1 - ( 1 - a*L**(-1./3) )**3.) def model((k, L0, a), t) : solution = odeint( func, array(L0[0]), array([0,t]), args=(a,k) ) return L0 - solution[1][0] params, chisq = leastSquaresFit(model, params, data) Unfortunately, this approach runs into an error (ValueError: shape mismatch: objects cannot be broadcast to a single shape) that seems to stem from the fact that leastSquaresFit is based on automatic derivation (DerivVar), and according to the manual "the function [that defines the model] may only use the mathematical functions known to the module FirstDerivatives". What is a good solution or workaround to this problem which appears to be quite a standard situation to me? Thanks for any help, harold. You might consider using numpy. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
