Re: psss...I want to move from Perl to Python

[Josef Pktd]

On Friday, January 29, 2016 at 4:50:25 PM UTC-5, Cody Piersall wrote:
> On Fri, Jan 29, 2016 at 2:42 PM, Fillmore 
> wrote:
> > I actually have a few followup question.
> 
> > - will iNotebook also work in Python 3?
> Yes!  And just FYI, it's called they Jupyter Notebook now, but pretty much
> everyone still (colloquially) calls it the IPython Notebook so you're in
> good company.  When you're searching online, you should search for Jupyter
> though, or you might get obsolete docs.
> 
> > - What version of Python 3 do you recommend I install on Windows?
> Might as well go for Python 3.5.
> 
> > [snip questions I don't know the answer to]
> > - Is there a good IDE that can be used for debugging? all free IDEs for
> Perl suck and it would be awesome if Python was better than that.
> PyCharm is a really good IDE.  You can use the community edition for free
> as long as it's for open source projects or your company makes less than $1
> million a year.  For bigger projects I use PyCharm, but it's not bad to use
> just a plain text editor either.  If your company is making $1 million a
> year, presumably they can afford the license fees.  Download link:
> https://www.jetbrains.com/pycharm/download/

spyder is great for developing scripts (especially data analysis and scientific)
pydev/eclipse is very good for larger packages or projects.

Great features: automatic, immediate code checking for finding those typos, 
undefined names and unused names, and similar  (look out for red)
(and of course code completion, nicer than in IDLE)

Another very useful tool for me during bug hunting sessions is to drop into the 
debugger when running nosetests.

In my experience notebooks are for when I know what I'm doing and want a nice 
summary or presentation, but not when I need to figure out what I'm supposed to 
be doing.

Josef

> 
> Cody

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GitHub's "pull request" is proprietary lock-in

[Josef Pktd]

On Monday, January 4, 2016 at 12:41:32 PM UTC-5, Michael Torrie wrote:
> On 01/04/2016 03:21 AM, m wrote:
> > W dniu 03.01.2016 o 05:43, Ben Finney pisze:
> >> That and other vendor-locked workflow aspects of GitHub makes it a poor
> >> choice for communities that want to retain the option of control over
> >> their processes and data.
> > 
> > I'm also afraid that Github will make to git the same thing as Google
> > did to Jabber/XMPP.
> > 
> > Decade ago, I had plenty of friends on my jabber contacts list. Next,
> > Google made it's talk compatible with jabber, then my friends slowly
> > migrated to gtalk, because if they used gmail anyway, then why not use
> > it also for jabber?
> > 
> > And then Google turned off XMPP support and suddenly I lost ability to
> > contact with 80% of my friends without having stupid hangouts running,
> > or without falling back to email (which is not so bad BTW).
> 
> I use gtalk with Pidgin every day using XMPP.  So Google still supports
> XMPP.  However what they stopped doing was allowing federated XMPP,
> which pretty much breaks XMPP, at least the spirit of it.  So the only
> way to chat with gtalk users is to use your gtalk account.  But you
> certainly don't need hangouts.  XMPP works fine between your client and
> the Google server.
> 
> I agree that Google really pulled a bad one with gtalk though.  Dropping
> federated XMPP support was definitely not in keeping with their original
> "do no evil" mantra.
> 
> > The same can be with Github and git. PPL will forget how to use git
> > without github. When Github will make git-incompatible changes, vast
> > majority will need/want to follow the changes and eg. will use Gitlabs
> > propertiary binary.
> 
> Yup you are correct.  However for the foreseeable future, you can still
> do a git clone from github, and you can still use your local repository
> normally.  In fact I think this is really part of the github workflow.
> But who knows what the future will bring.  I can sure see the wisdom of
> the GPLv3 as we move into a world of software as a service, where even
> Microsoft uses Linux, and charges us for it.


about:
> PPL will forget how to use git without github.

We cannot forget what we never learned. 

git is way to complicated for regular users without support like what github 
provides.

I haven't done a merge without the Green Button in a long time. And when I did 
I always had to triple check to make sure to avoid any mistakes.
I never needed to check what a pull request would be in pure git.

Josef
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Installing PyCharm on Windows

[Josef Pktd]

On Sunday, December 20, 2015 at 3:29:34 AM UTC-5, Thomas 'PointedEars' Lahn 
wrote:
> Josef Pktd wrote:
> ^^
> I doubt that is your real name.

But it's the name I used for almost all of my Python open source development, 
and can be easily googled.
except I misspelled my "name" josef-pkt when I set up my github account.


> 
> > On Saturday, December 19, 2015 at 1:32:27 PM UTC-5, Thomas 'PointedEars'
> > Lahn wrote:
> >> Have you tried to install Python ≥ 3.4.4rc1 on Windows XP?  If yes, it
> >> cannot work; you need Python < 3.4.4rc1 instead (and you should seriously
> >> consider upgrading Windows or even better, to switch to a real operating
> >> system, like GNU/Linux – many of the latter come for free and give you
> >> more freedom than Windows):
> > 
> > Thanks for the tip, I will switch away from Windows when I have an extra
> > year to figure out weird things in other operating systems.
> 
> Ordinary people (as opposed to tech-savvy people) have been known to set up 
> a current Linux distribution in a day and get accustomed to it in a week.  
> Those “weird things” you are talking about are merely something that needs a 
> little getting used to if you had gotten used to Windows.  Of course, not 
> all people are (still) that flexible in their thinking.

Maybe I don't **want** to be this flexible because I allocate my "flexibility" 
to other things (instead of, for example, figuring out how packaging and paths 
work on Linux).


> 
> > So far I never managed more than two weeks in a Linux virtual machine
> > before never opening it again.
> 
> Your problem alone.

If I have a problem, then I assume many other Windows users will also have 
problems, if they are even willing to try.


> 
> > PPS: The mainstream: Python and Windows ("it's not just for 'hackers'"):
> 
> Non-Windows operating systems are not just for hackers since more than a 
> decade.  They are for reasonably smart people, though, who would not give up 
> at the first sign of trouble.
> 
> And who cares about the mainstream opinion?

I do!

Almost all economists and econometricians that I know are using Windows. And I 
was working for many years on open software to get to a stage where they can 
use Python instead of commercial packages like GAUSS, Stata or Matlab.

The main target group are not programmers or users with a computer science 
background.

> 
> > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> 
> Thank you so much for providing that valuable reference. I am sure nobody 
> here knew :->
> 
> > https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
> 
> A million flies can be wrong.
> 
> <https://en.wikipedia.org/wiki/Microsoft_Windows#Third-party_analysis>
> 
> > PPPS: Scientific Python mailing list have been free of snide remarks about
> > Windows users for a while, but not of real problems with Windows (or OSX
> > or Linux)
> 
> Thanks to you that would have changed if this were a “scientific Python 
> mailing list”.

I complained a few times on the mailing lists when the response to a question 
by a Windows users was to switch to Linux. It's not helpful in almost all 
cases, and now the standard response for setup problems is to use Anaconda or 
WinPython.

I also found it silly if Software Carpentry courses use exclusively Linux in 
the course and people are then surprised that users go back to their office and 
their Windows machine, and their commercial software, ignoring most of what 
they learned.


> 
> Mine was not a snide remark, but the truth.  Those other operating systems I 
> was talking about do give users more freedom.  For example, the freedom to 
> use it on as many different machines as you like without an extra license, 
> to see the source code, to modify it, and to redistribute the modification 
> including an attribution to yourself.

"Richtige Männer nehmen Pitralon"  everything else is "unreal"

I'm writing BSD licensed software, but I never felt the urge to change more 
than a few options in the operating system, and was never interested in the 
"freedom" to fix the kernel (and I was never interested in fixing my car 
either).

Josef

PS: I learned a lot from this mailing list when I started with Python 12 to 15 
years ago. But either the mailing list or my perception has changed in that I 
see now several or many comments that ignore that there are many users and 
developers using Python without an explicit programming background.



>  
> > S: Windows 10 with Computer as a Service following Apple will lock in
> > many users again to "everything

Re: Installing PyCharm on Windows (was: issues)

[Josef Pktd]

On Saturday, December 19, 2015 at 1:32:27 PM UTC-5, Thomas 'PointedEars' Lahn 
wrote:
> Anna Szaharcsuk wrote:
> 
> > I was trying to install PyCharm, but didn't worked and needed interpreter.
> > the computer advised to install the python for windows.
> 
> Not “the python for windows” (that would be some species of snake), but 
> _Python_ for _Windows_, the programming language interpreter.  Just do as 
> “the computer advised”.
> 
> > Can you help me, please, PyCharm stillnot working...allways gives a
> > message for repair, after- the repair successful and again message for
> > repair...
> 
> Have you installed Python first?  If no, it cannot work (and please think 
> about this: What good is an IDE/editor for a programming language if you do 
> not also have the interpreter/compiler?).  It says so in the “Quick Start 
> Guide” in the “PyCharm 5.0 Help”, currently to be found on the PyCharm Web 
> site under “Docs & Demos”:
> 
> 
> 
> Have you tried to install Python ≥ 3.4.4rc1 on Windows XP?  If yes, it 
> cannot work; you need Python < 3.4.4rc1 instead (and you should seriously 
> consider upgrading Windows or even better, to switch to a real operating 
> system, like GNU/Linux – many of the latter come for free and give you more 
> freedom than Windows):

Thanks for the tip, I will switch away from Windows when I have an extra year 
to figure out weird things in other operating systems.

So far I never managed more than two weeks in a Linux virtual machine before 
never opening it again.


Josef
PS: loyal Windows user since Windows 95, currently considering whether to 
upgrade from 7 and 8 to 10.

PPS: The mainstream: Python and Windows ("it's not just for 'hackers'"):
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

PPPS: Scientific Python mailing list have been free of snide remarks about 
Windows users for a while, but not of real problems with Windows (or OSX or 
Linux)

S: Windows 10 with Computer as a Service following Apple will lock in many 
users again to "everything Microsoft", but without the monopoly.


> 
> 
> 
> Before your next posting, please read
> 
> 
> 
> -- 
> PointedEars
> 
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help on error " ValueError: For numerical factors, num_columns must be an int "

[Josef Pktd]

On Wednesday, December 16, 2015 at 9:50:35 AM UTC-5, Robert wrote:
> On Wednesday, December 16, 2015 at 6:34:21 AM UTC-5, Mark Lawrence wrote:
> > On 16/12/2015 10:44, Robert wrote:
> > > Hi,
> > >
> > > When I run the following code, there is an error:
> > >
> > > ValueError: For numerical factors, num_columns must be an int
> > >
> > >
> > > 
> > > import numpy as np
> > > import pandas as pd
> > > from patsy import dmatrices
> > > from sklearn.linear_model import LogisticRegression
> > >
> > > X = [0.5,0.75,1.0,1.25,1.5,1.75,1.75,2.0,2.25,2.5,2.75,3.0,3.25,
> > > 3.5,4.0,4.25,4.5,4.75,5.0,5.5]
> > > y = [0,0,0,0,0,0,1,0,1,0,1,0,1,0,1,1,1,1,1,1]
> > >
> > > zipped = list(zip(X,y))
> > > df = pd.DataFrame(zipped,columns = ['study_hrs','p_or_f'])
> > >
> > > y, X = dmatrices('p_or_f ~ study_hrs', df, return_type="dataframe")
> > > ===
> > >
> > > I have check 'df' is this type:
> > > =
> > > type(df)
> > > Out[25]: pandas.core.frame.DataFrame
> > > =
> > >
> > > I cannot figure out where the problem is. Can you help me?
> > > Thanks.
> > >
> > > Error message:
> > > ..
> > >
> > >
> > > ---
> > > ValueErrorTraceback (most recent call 
> > > last)
> > > C:\Users\rj\pyprj\stackoverflow_logisticregression0.py in ()
> > >   17 df = pd.DataFrame(zipped,columns = ['study_hrs','p_or_f'])
> > >   18
> > > ---> 19 y, X = dmatrices('p_or_f ~ study_hrs', df, 
> > > return_type="dataframe")
> > >   20
> > >   21 y = np.ravel(y)
> > >
> > > C:\Users\rj\AppData\Local\Enthought\Canopy\User\lib\site-packages\patsy\highlevel.pyc
> > >  in dmatrices(formula_like, data, eval_env, NA_action, return_type)
> > >  295 eval_env = EvalEnvironment.capture(eval_env, reference=1)
> > >  296 (lhs, rhs) = _do_highlevel_design(formula_like, data, 
> > > eval_env,
> > > --> 297   NA_action, return_type)
> > >  298 if lhs.shape[1] == 0:
> > >  299 raise PatsyError("model is missing required outcome 
> > > variables")
> > >
> > > C:\Users\rj\AppData\Local\Enthought\Canopy\User\lib\site-packages\patsy\highlevel.pyc
> > >  in _do_highlevel_design(formula_like, data, eval_env, NA_action, 
> > > return_type)
> > >  150 return iter([data])
> > >  151 design_infos = _try_incr_builders(formula_like, 
> > > data_iter_maker, eval_env,
> > > --> 152   NA_action)
> > >  153 if design_infos is not None:
> > >  154 return build_design_matrices(design_infos, data,
> > >
> > > C:\Users\rj\AppData\Local\Enthought\Canopy\User\lib\site-packages\patsy\highlevel.pyc
> > >  in _try_incr_builders(formula_like, data_iter_maker, eval_env, NA_action)
> > >   55   data_iter_maker,
> > >   56   eval_env,
> > > ---> 57   NA_action)
> > >   58 else:
> > >   59 return None
> > >
> > > C:\Users\rj\AppData\Local\Enthought\Canopy\User\lib\site-packages\patsy\build.pyc
> > >  in design_matrix_builders(termlists, data_iter_maker, eval_env, 
> > > NA_action)
> > >  704 factor_states[factor],
> > >  705 
> > > num_columns=num_column_counts[factor],
> > > --> 706 categories=None)
> > >  707 else:
> > >  708 assert factor in cat_levels_contrasts
> > >
> > > C:\Users\rj\AppData\Local\Enthought\Canopy\User\lib\site-packages\patsy\design_info.pyc
> > >  in __init__(self, factor, type, state, num_columns, categories)
> > >   86 if self.type == "numerical":
> > >   87 if not isinstance(num_columns, int):
> > > ---> 88 raise ValueError("For numerical factors, 
> > > num_columns "
> > >   89  "must be an int")
> > >   90 if categories is not None:
> > >
> > > ValueError: For numerical factors, num_columns must be an int
> > >
> > 
> > Slap the ValueError into a search engine and the first hit is 
> > https://groups.google.com/forum/#!topic/pystatsmodels/KcSzNqDxv-Q

This was fixed in patsy 0.4.1 as discussed in this statsmodels thread.
You need to upgrade patsy from 0.4.0.

AFAIR, the type checking was too strict and broke with recent numpy versions.

Josef


> > 
> > -- 
> > My fellow Pythonistas, ask not what our language can do for you, ask
> > what you can do for our language.
> > 
> > Mark Lawrence
> 
> Hi,
> I don't see a solution to my problem. I find the following demo code from 
> 
> https://patsy.readthedocs.org/en/v0.1.0/API-reference.html#patsy.dmatrix
> 
> It doesn't work either on the Canopy. Does it work on your computer?
> Thanks,
> 
> /
> demo_data("a", "x", nlevels=3)
> Out[134]: 

Re: Is vars() the most useless Python built-in ever?

[Josef Pktd]

On Monday, November 30, 2015 at 8:01:14 PM UTC-5, Steven D'Aprano wrote:
> I'm trying to understand why vars() exists. Does anyone use it?
> 
> Every time I try to use it, I find it doesn't quite do what I want. And even
> if it did, there are more obvious and/or correct alternatives.
> 
> For instance, I want to check whether a particular name is an instance
> attribute. So first I write:
> 
> "name" in obj.__dict__
> 
> but when I see the dunder name I think that's an implementation detail. And
> sure enough, not all instances have a __dict__ (e.g. if it uses __slots__
> instead) and so I re-write it as:
> 
> "name" in vars(obj)
> 
> but that also fails if obj has no instance __dict__.
> 
> But why am I looking just in the instance __dict__? Chances are I should be
> looking for the attribute *anywhere* in the instance/class/superclass
> hierarchy: 
> 
> hasattr(obj, "name")
> 
> Or, if you are worried about triggering dynamic attributes using
> __getattr__, you can do this:
> 
> sentinel = object()
> inspect.getattr_static(obj, "name", sentinel) is not sentinel
> 
> which only checks for pre-existing attributes without triggering
> __getattr__, __getattribute__, or the descriptor protocol.
> 
> 
> Either way, vars() doesn't solve the problem. What problem does it solve?

I'm using dir and vars pretty often when I'm trying to figure out new code or 
review a pull request, or when I'm reviewing code that I don't remember.

Both are convenient for quickly checking which attributes are available at the 
moment. I never realized that there might be issues with "fancy" problems. 

`vars` is convenient, for example, to check which attributes have been 
initialized to None, and which already have assigned values. And checking again 
after some calculations, I roughly see which attributes have been added or 
changed in the mean time.

aside: I'm boring and like code that has no magic, especially if I have to 
maintain it.

Josef

> 
> 
> 
> -- 
> Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 9:40:56 AM UTC-4, Steven D'Aprano wrote:
> On Tue, 13 Oct 2015 06:55 pm, Todd wrote:
> 
> > On Oct 13, 2015 2:11 AM, "Steven D'Aprano" <...> wrote:
> 
> >> Consider the following piece of code:
> >>
> >> def addone(x):
> >> return x + 1
> >>
> >>
> >> The human programmer reading that can trivially infer that x must be a
> >> number (or at least something which supports numeric addition). So can
> >> the compiler. In a strongly typed language with no numeric promotion, the
> >> compiler can infer that x must be an int. In a language with numeric
> >> promotion, it can infer that x must be an int or float.
> > 
> > Or a decimal, complex number, numpy array, any one of a dozen or so pandas
> > classes, any one of the dozen or so units classes, sympy variable, etc...

A good example is `y = x * 2` followed by long calculations with y.

I have no idea what this does if I don't know the type of x.
(list and tuples get duplicated, arrays as in numpy or pandas multiply 
elementwise, matrix packages use dot (@) product. Two out of three will give us 
the wrong result but don't raise a runtime exception.)

The flip side of the flexibility with dynamic typing is that we spend a lot of 
time and effort in asserting or converting types.

There are cases when being able to quack is not enough, it needs to have the 
right quack. And when we allow for different sounds created by the duck 
look-a-likes, then code can get complicated and avoiding subtle mistakes will 
become very difficult.

Annotations might help the editors, but doesn't enforce the right behavior.
Also, in some cases we don't want to restrict ducktyping in the function or 
method arguments but we need to protect our calculations. Function annotations 
won't help her.

One common pattern then guarantees fixed types within a function:

def calculate_something(x):


x = numpy.asarray(x, numpy.float64)  # convert anything array_like to array

do calculations that only use numpy arrays


return result

In the center we have static types (as far as numpy arrays are static), and we 
don't have to guess on what methods are actually doing, and code inspection 
could infer this.

Outside we still have all the flexibility of duck typing.

I guess it's gradual typing but not through unenforced function annotations.

Josef


> 
> I knew my over-simplification would get me in trouble...
> 
> Firstly, if we're talking about Python specifically, the compiler won't
> actually infer anything (see PEP 484, which "assumes the existence of a
> separate off-line type checker which users can run over their source code
> voluntarily"). It is up to the external type checker (or linter, IDE,
> documentation generator, refactoring tool, etc) to perform any type checks.
> 
> Secondly, what the tool actually infers will depend on the tool. I would
> expect that a basic type checker (say, in a text editor) will infer that x
> is an int or float only. A more powerful checker might infer the Number ABC
> (Abstract Base Class). A specialist checker might even know about numpy,
> pandas, units and sympy, but I wouldn't expect a general-purpose type
> checker to infer them.
> 
> If the programmer cares about such specialist types, then she can easily add
> type hints to supplement the checker's type inference, or the checker
> itself may be configurable. That's a *quality of implementation* detail.
> 
> The beauty of *gradual typing* is that you don't have to care about every
> possible class in the entire universe of Python code, only about the
> classes you actually care about in the parts of your code you choose to
> type check.
> 
> http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/
> 
> Because the Python interpreter itself doesn't care about the compile-time
> type checking, if the checker gets in your way, you can just *not run it*.
> I also expect that good checkers will include directives to skip sections
> of code, so you can include annotations as documentation while still
> silencing over-strict or incorrect compile-time type errors. (Runtime type
> errors will still occur as normal.)
> 
> 
> 
> -- 
> Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 2:52:32 PM UTC-4, Sibylle Koczian wrote:
> Am 13.10.2015 um 00:10 schrieb Ben Finney:
> > Sibylle Koczian <> writes:
> >
> >> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> >>> Auto-complete is a fine and useful tool. But if you are crippled as a
> >>> programmer without it, well, then you can hardly claim to understand the
> >>> language or framework you are programming in if you cannot use it without
> >>> an IDE doing half the work for you.
> >>>
> >>
> >> Well ... you're certainly quite right as far as Python and its
> >> standard library is concerned. But I don't know who would really want
> >> to use .NET without auto-complete and for all I know Java may be just
> >> as awful.
> >
> > Yes, and that is quite compatible with Steven's assertion. The two
> > assertions:
> >
> > * A programmer who feels crippled without auto-complete cannot claim to
> >understand the language or framework they're programming in.
> >(assertion made by Steven)
> >
> > * The overwhelming majority of .NET and Java programmers would feel
> >crippled without auto-complete. (assertion made by Sibylle)
> >
> Not really wanting to do without x isn't the same as feeling crippled 
> without it.

To support this

I have been writing numpy/scipy based code in python for many years, and still 
I make a lot more mistakes without autocompletion and having pyflakes or 
similar run in the editor in the background.

I know roughly where everything is in a large class hierarchy with more 
information hidden in attached classes (instances). But it's easy to figure out 
the details with code completion and standard inspection.
It works pretty well maybe 90 % of the time (except in chained expressions).
I also memorize only the main arguments in the signatures, and rely for the 
rest on the pop-up hints.

> 
> > can both be true. An obvious resolution is to conclude that the
> > overwhelming majority of Java and .NET programmers cannot claim to
> > understand those technologies.
> >
> I don't think you can measure understanding by the ability and 
> willingness (!) to type those overlong and yet similar names again and 
> again in full.
> 
> > Python, on the other hand, has the huge advantage that programming in
> > even a bare minimal editor is feasible, and editor features that make
> > the programmer's life easier are conveniences, not essential to be
> > competent in Python.
> >
> Only one of its huge advantages. As long as no GUI is necessary ... but 
> that's another story.

I don't know about GUI programming, but even though it's not part of the 
language there are packages for example for asserting and maintaining types and 
restriction on values like traits and traitlets.

Josef


> 
> Sibylle

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyarmor, guard your python scripts

[Josef Pktd]

On Monday, October 5, 2015 at 11:27:58 PM UTC-4, Ian wrote:
> On Oct 5, 2015 4:27 PM, "Ben Finney"  wrote:
> 
> >
> 
> > Josef Pktd  writes:
> 
> >
> 
> > > related
> 
> >
> 
> > Care to give us a summary of what that is, and describe what you think
> 
> > is the relevant point?
> 
> Following the link reveals it to be the video of a talk on Python exe 
> compilation from PyCon 2014.
> 
> If you're worried about the safety of the link, know that youtu.be is the 
> official URL shortener for YouTube and only leads to YouTube videos.

The talk is by Brandon Rhodes that I found quite refreshing the first time I 
attended Pycon https://us.pycon.org/2014/schedule/presentation/201/
The approach is building an exe file, but the motivation is the same as here.

About the keys:

Consider it as price discrimination between "cheap" hackers and plain users.

When I was a student I wasn't very reluctant to install cracked versions, but 
as far as I remember, I haven't installed a cracked version of a program in 15 
years or so. 
All the application and music on the ipads in my family are legitimate 
versions, either free minimal functionality versions or purchased on apps store 
or through itunes.

The python community in general seems to be a lot in favor of SaaS but not much 
in favor of selling (small) software products. When we got our first ipad, (I'm 
traditionally a Windows user) I was surprised how large the market for small 
and larger programs is and the opportunities that it provides for single 
developers or small groups of developers. In contrast, SaaS requires a much 
larger setup cost and larger scale.

I pretty much share Jondy Zhao's view.


That doesn't mean it's always a good idea. I have been working for many years 
on BSD licensed open source software.

Josef

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyarmor, guard your python scripts

[Josef Pktd]

related
https://youtu.be/wsczq6j3_bA?t=20m9s

Josef
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: linregress and polyfit

[Josef Pktd]

On Tuesday, September 17, 2013 10:34:39 PM UTC-4, Krishnan wrote:
> I created an xy pair
> 
> 
> 
> y = slope*x + intercept
> 
> 
> 
> then I added some noise to "y" using
> 
> 
> 
> numpy.random.normal - call it z 
> 
> 
> 
> I could recover the slope, intercept from (x,y) using linregress
> 
> BUT cannot calculate the slope, intercept from (x, z)
> 
> 
> 
> What is puzzling is that for both pairs (x,y) and (x,z) the
> 
> polyfit (order 1) works just fine (gives me the slope, intercept)
> 
> --
> 
> import numpy as np
> 
> import scipy
> 
> # create a straight line, y= slope*x + intercept 
> 
> x = np.linspace(0.0,10.0,21)  
> 
> slope = 1.0  
> 
> intercept = 3.0   
> 
> y = []  
> 
> for i in range(len(x)):  
> 
> y.append(slope*x[i] + intercept)  
> 
> # now create a data file with noise
> 
> z= []  
> 
> for i in range(len(x)):  
> 
> z.append(y[i] + 0.1*np.random.normal(0.0,1.0,1))  

When z is converted to a numpy array then it has an extra dimension that 
linregress cannot handle, because np.random.normal(0.0,1.0, 1) returns an array 
and not a scalar.

much easier: use vectorized numpy instead of loop

z = y + 0.1*np.random.normal(0.0,1.0, len(y))

which is a one dimensional array and works with linregress

Josef

> 
> # now calculate the slope, intercept using linregress
> 
> from scipy import stats  
> 
> # No error here this is OK, works for x, y
> 
> cslope, cintercept, r_value, p_value, std_err = stats.linregress(x,y)
> 
> print cslope, cintercept
> 
> # I get an error here
> 
> #ValueError: array dimensions must agree except for d_0
> 
> nslope, nintercept, nr_value, np_value, nstd_err = stats.linregress(x,z)  
> 
> print nslope, nintercept
> 
> # BUT polyfit works fine, polynomial or order 1 with both data sets
> 
> ncoeffs = scipy.polyfit(x,z,1)  
> 
> print ncoeffs
> 
> coeffs = scipy.polyfit(x,y,1)  
> 
> print coeffs
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: statsmodels.api

[Josef Pktd]

On Tuesday, September 17, 2013 9:06:59 AM UTC-4, Oscar Benjamin wrote:
> On 17 September 2013 13:13, Davide Dalmasso  wrote:
> 
> >
> 
> > You are right... there is a problem with scipy intallation because this 
> > error arise...
> 
> >
> 
>  from scipy.interpolate import interp1d
> 
> > Traceback (most recent call last):
> 
> >   File "", line 1, in 
> 
> > from scipy.interpolate import interp1d
> 
> >   File "C:\Python33\lib\site-packages\scipy\interpolate\__init__.py", line 
> > 150, in 
> 
> > from .interpolate import *
> 
> >   File "C:\Python33\lib\site-packages\scipy\interpolate\interpolate.py", 
> > line 12, in 
> 
> > import scipy.special as spec
> 
> >   File "C:\Python33\lib\site-packages\scipy\special\__init__.py", line 529, 
> > in 
> 
> > from ._ufuncs import *
> 
> > ImportError: DLL load failed: Impossibile trovare il modulo specificato.
> 
> >
> 
> > I tryed to re-install the scipy executable that I downloaded from 
> > http://www.lfd.uci.edu/~gohlke/pythonlibs/
> 
> > but the problem persists
> 
> 
> 
> There are potential compatibility problems with the binaries from
> 
> there as described at the top of the page. One thing is that you need
> 
> to use Christopher's own numpy build to go with scipy:
> 
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
> 
> If you installed numpy from somewhere else then that could be your problem.
> 
> 
> 
> Essentially scipy isn't quite ported to Python 3.3 yet so my general
> 
> advice is to use Python 3.2 and to use the official numpy/scipy
> 
> binaries from sourceforge (they don't yet provide binaries for 3.3).
> 
> 
> 
> Alternatively an easier approach might be to use Python(x, y) (which
> 
> is free) or the Enthought Python Distribution (which is free for
> 
> academic users). These are distributions that bundle Python with
> 
> numpy/scipy and lots of other packages. I think they both still use
> 
> Python 2.7 though.
> 
> 
> 
> (As an aside, this is all much simpler if you're using Ubuntu or some
> 
> other Linux distro rather than Windows.)

scientific python on a stick

https://code.google.com/p/winpython/wiki/PackageIndex_33

I haven't seen any problems so far on python 3.3
The statsmodels test suite passes without problems on python 3.3 also, as far 
as I remember.
(and no problems using Windows. just use the right binaries.)

Josef

> 
> 
> 
> 
> 
> Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: statsmodels.api

[Josef Pktd]

On Tuesday, September 17, 2013 8:13:27 AM UTC-4, Davide Dalmasso wrote:
> You are right... there is a problem with scipy intallation because this error 
> arise...
> 
> 
> 
> >>> from scipy.interpolate import interp1d
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
> from scipy.interpolate import interp1d
> 
>   File "C:\Python33\lib\site-packages\scipy\interpolate\__init__.py", line 
> 150, in 
> 
> from .interpolate import *
> 
>   File "C:\Python33\lib\site-packages\scipy\interpolate\interpolate.py", line 
> 12, in 
> 
> import scipy.special as spec
> 
>   File "C:\Python33\lib\site-packages\scipy\special\__init__.py", line 529, 
> in 
> 
> from ._ufuncs import *
> 
> ImportError: DLL load failed: Impossibile trovare il modulo specificato.
> 
> 
> 
> I tryed to re-install the scipy executable that I downloaded from 
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
> 
> but the problem persists

Did you also install numpy from gohlke?
My guess would be binary incompatibility if numpy is not the MKL version.

Josef
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 450 Adding a statistics module to Python

[Josef Pktd]

I think the install issues in the pep are exaggerated, and are in my opinion 
not a sufficient reason to get something into the standard lib.

google appengine includes numpy
https://developers.google.com/appengine/docs/python/tools/libraries27

I'm on Windows, and installing numpy and scipy are just binary installers that 
install without problems.
There are free binary distributions (for Windows and Ubuntu) that include all 
the main scientific applications. One-click installer on Windows
http://code.google.com/p/pythonxy/wiki/Welcome
http://code.google.com/p/winpython/

How many Linux distributions don't include numpy? (I have no idea.)

For commercial support Enthought's and Continuum's distributions include all 
the main packages.

I think having basic descriptive statistics is still useful in a basic python 
installation. Similarly, almost all the descriptive statistics moved from 
scipy.stats to numpy.

However, what is the longterm scope of this supposed to be?

I think working with pure python is interesting for educational purposes
http://www.greenteapress.com/thinkstats/
but I don't think it will get very far for more extensive uses. Soon you will 
need some linear algebra (numpy.linalg and scipy.linalg) and special functions 
(scipy.special).

You can reimplement them, but what's the point to duplicate them in the 
standard lib?

For example:

t test: which versions? one-sample, two-sample, paired and unpaired, with and 
without homogeneous variances, with 3 alternative hypothesis.

If we have t test, shouldn't we also have ANOVA when we want to compare more 
than two samples?

...

If the Python versions that are not using a C backend need a statistics package 
and partial numpy replacement, then I don't think it needs to be in the CPython 
lib.


If think the "nuclear reactor" analogy is in my opinion misplaced.

A python implementation of statistics is a bycycle, numpy is a car, and if you 
need some heavier lifting in statistics or machine learning, then the trucks 
are scipy, scikit-learn and statsmodels (and pandas for the data handling).
And rpy for things that are not directly available in python.


I'm one of the maintainers for scipy.stats and for statsmodels.

We have a similar problem of deciding on the boundaries and scope of numpy, 
scipy.stats, pandas, patsy, statsmodels and scikit-learn. There is some overlap 
of functionality where the purpose or use cases are different, but in general 
we try to avoid too much duplication.


https://pypi.python.org/pypi/statsmodels
https://pypi.python.org/pypi/pandas
https://pypi.python.org/pypi/patsy  (R like formulas)
https://pypi.python.org/pypi/scikit-learn


Josef
-- 
http://mail.python.org/mailman/listinfo/python-list