Re: Confused with Functions and decorators

[Steven D'Aprano]

On Sat, 19 Jul 2014 03:52:18 -0700, Jerry lu wrote:

> Ok so i am trying to learn this and i do not understand some of it. I
> also tried to searched the web but i couldnt find any answers.
> 
> 1. I dont understand when i will need to use a function that returns
> another function. eg
>def outer():
>  def inner():
>x = 5
>   return inner
> 
>  why not just use inner and forget about the whole outer function?

For the example given, there's no point in using an inner function. 
(Especially since the inner function does nothing useful.) But there are 
three common reasons for writing inner functions:

#1 Encapsulation and information hiding.

If you've ever programmed in Pascal, this may be familiar to you. You use 
inner functions to hide them away from code outside of the function. Here 
is a toy example that shows the basic idea:

def function(x):
def increment(x):
return x + 1
y = increment(x)
print x, y


In Python, I would rarely bother to write code like that. I'd just make 
the increment function a top-level function, marked as "private" with a 
leading underscore: _increment.

One place where the Pascal-style nested function may be useful is with 
recursive functions:

def factorial(n):
if not isinstance(n, int):
raise TypeError("n must be an integer")
if not n >= 0:
raise ValueError("n must be zero or positive")
def inner_fact(n):
if n <= 1:
return 1
return n*inner_fact(n-1)
return inner_fact(n)


This has three advantages:

* The caller cannot (easily) bypass the outer function and call the inner 
function directly.

* The outer function performs all the argument checking and any pre-
processing once only, the inner function can safely assume the argument 
is valid and eschew pointless error checking.

* The outer function can be renamed without breaking the recursion.



#2 Don't Repeat Yourself (DRY)

Sometimes you may have a big function that performs the same chunk of 
code in two places. For example, you might write a function which 
processes a file, and you want to accept either an open file object or a 
file name:

def process(the_file):
def do_stuff(fp):
for line in fp:
print line
if isinstance(the_file, str):
with open(the_file, 'r') as f:
do_stuff(f)
else:
do_stuff(the_file)


Again, it is common to put do_stuff as a private top-level function, but 
if you want to hide it away as an internal function, you can.


#3 Closures and factory functions

But now we come to the most important reason to use internal functions. 
All of the inner functions I've shown so far have been ordinary functions 
that merely happened to be nested inside another function. But when we 
come to closures, that is not the case.

A closure is an inner function which "remembers" the state of its 
environment when called. Here's a basic example:

def make_incrementer(inc):
"""Make an new function which increments its argument by inc.

Examples of use:

>>> add_one = make_incrementer(1)
>>> add_two = make_incrementer(2)
>>> add_one(7)
8
>>> add_two(7)
9

"""
def incrementer(x):
return x + inc
return incrementer


This takes more effort to explain than to write!

The "make_incrementer" function is a *factory function*. It builds a new 
function each time it is called, then returns it. What does this new, 
inner, function do? It takes a single argument, x, and returns x + inc.

Where does the inner function get the value of inc from? This is what 
makes it a closure -- it gets the value of inc from the outer function, 
the factory. How it works is something like like this:

make_incrementer(3)

=> build a function "incrementer" which takes a single argument x
=> take a snap-shot of the state of make_incrementer function
   which includes inc=3
=> stuff that snap-shot into the incrementer function
=> return the incrementer function


Now, whenever you call that newly returned function, it will always see 
its own private snap-shot that includes inc=3.

The use of closures and factory functions is the most common, and 
powerful, use for inner functions. 9 times out of 10, if you see a 
decoratored function:

@decorator
def func(arg):
pass


the decorator is a factory function which takes an function as argument, 
and returns a new function which which includes the old function inside 
the closure. But that's now getting into more advanced territory.



> 2. This is more yes or no question when you pass in a func into another
> func as a parameter do you need to specify the parameter that the func
> is being passed into as func?

No.

You can pass functions around from place to place until the cows come 
how, stuff them into lists and dicts, extract them again, and not care 
one iota about its arguments until you actually 

Re: Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])

[Gregory Ewing]

Chris Angelico wrote:

Other people had, for instance, a C:\BELFRY (best place to have BATs,
you know), or other such names. What's your favorite
directory/repository name for a concretion of ... random stuff?


My project directories typically contain a directory
called "Attic" for putting stuff in that I probably
won't use any more, but want to keep just in case.

Fortunately, it doesn't have the same space restrictions
as its physical namesake. :-)

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

Re: OT: usenet reader software

[Chris Angelico]

On Sun, Jul 20, 2014 at 1:48 PM, Monte Milanuk  wrote:
> For whatever reason I never really tried tin (or trn).  I might have to
> give them a whirl... though I must say that using slrn seems kind of
> like riding a bicycle... my fingers apparently remember more than my
> brain does ;)

Heh, totally. I go back to an old game for some reason, and my fingers
know exactly what the Quick Save key is. My brain knows that there are
function keys for quick save and quick load in a lot of programs, but
is never sure which is which (and it'd be pretty bad to hit the wrong
one)... but my fingers always get it right. F1 and F4 for American
McGee's Alice, and F9 and F10 for Captain Bible... F6 in C&C Renegade
(that one's easy, there's no quick load)... Ctrl-X in Angband,
although that doesn't quite count... yep, my fingers know them a lot
better than my brain does.

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

Re: OT: usenet reader software

[Chris Angelico]

On Sun, Jul 20, 2014 at 1:44 PM, Monte Milanuk  wrote:
> That said, the irony that there seems to be a distinct *lack* of GUI
> usenet reader programs for Linux just kills me. Seems like its either Pan,
> or knode if you're into KDE.  Otherwise... you get to go dredge up old
> CLI programs like this one (slrn).  Works pretty well (better than I
> remember, actually) but still... having to exit the program and restart
> it to open a different server is *very* old-school :/

When I wanted to post a question to sci.math, I ended up with Xpn,
which seems decent. Got it from the Debian Wheezy repo, so it's
convenient to grab. Out of curiosity I just now went back there, found
the thread I'd started (no new posts), and skimmed everything that had
come in since then. What I'm seeing is:

1) Heaps of threads by one John Gabriel, which have in several cases
been followed up with public service announcements saying "CRANK
ALERT". He seems to be the sci.math equivalent of either Ranting Rick
or jmf... but worse than either by a significant margin. Seriously, he
makes me happy about how well-off c.l.p is.
2) Other "crank" threads, boasting of how Newton is right and Einstein
wrong, or something. I'm not sure if Archimedes Plutonium is an alias
of John Gabriel or not, but I can't be bothered reading the threads to
find out.
3) Straight-up spam about adwords, "Islam is not a Religion of
Extremism" (which comes through to c.l.p too, and even crosses the
boundary to python-list at times; I see some of that in my Gmail spam
box), etc
4) A few homework problems, again similar to what we see here
5) About two threads, and this across roughly two and a half weeks,
that are actually interesting and potentially useful.

I might be overstating the problem a bit; a sci.math regular might
read a bunch of them and find that a few more are useful than the ones
that I picked out based on their subject lines. But certainly there is
a LOT of spam there. Not as much as there is utter junk that isn't
spam (ridiculous crank-posted rubbish outnumbers spam threads by
probably 3:1 or more), but still a lot of spam.

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Tim Delaney]

On 20 July 2014 11:53, C.D. Reimer  wrote:

>
> On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
>
>> I haven't used Python on Windows much, but when I did use it, I found the
>> standard Python interactive interpreter running under cmd.exe to be bare-
>> bones but usable for testing short snippets. If I recall correctly, it is
>> missing any sort of command history or line editing other than backspace,
>> which I guess it would have been painful to use for extensive interactive
>> work, but when I started using Python on Linux the interactive interpreter
>> had no readline support either so it was just like old times :-)
>>
>
> Windows PowerShell supports very basic Linux commands and has a command
> history. I'm always typing "ls" for a directory listing when I'm on a
> Windows machine. The regular command line would throw a DOS fit. PowerShell
> lets me get away with it.
>
> http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_
> of_cmdlets_with_similar_commands
>
> I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is
> dying and MacBook shuts down after 15 minutes. I'm surprised at how well I
> was able to set up a equivalent programming environment on Windows.


I advise anyone who works cross-platform to install MSYS on their Windows
boxes (for the simplest, most consistent behaviour ignore rxvt and just
launch bash -l - i directly). Or use cygwin if you prefer.

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

Re: OT: usenet reader software

[Monte Milanuk]

On 2014-07-19, c...@isbd.net  wrote:
> memilanuk  wrote:
>> 
>> Guess where I'm going with this is... is there anything out there worth 
>> trying - on Linux - that I'm missing?
>> 
> If slrn was a maybe then there's also tin for text mode news readers,
> it's what I have always used.  I don't know what it does with HTML as
> none of the groups I frequent ever have any HTML in them.
>
> It does add one 'GUIness' to its text mode, it's mouse aware so you
> can click on messages in a list to open them.

slrn does have that option as well... just needs turned on (its off by
default) in the config file.  I seem to recall it not working so hot...
but I tried it on a link in a post last night and it worked like a
peach.

For whatever reason I never really tried tin (or trn).  I might have to
give them a whirl... though I must say that using slrn seems kind of
like riding a bicycle... my fingers apparently remember more than my
brain does ;)

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

Re: OT: usenet reader software

[Monte Milanuk]

On 2014-07-19, Martin S  wrote:
> Is there a point to still use Usenet? Last time I checked noise overwhelm
> ed signal by a factor of something close to 542.

Martin,

Fair enough question.  Seems like a lot of usenet groups have become
spam-fests, and using it to d/l various binaries of questionable origin
seems to be the major 'driving force' for a lot of people any more - for
pure usenet.  As others point out, you can filter the spam fairly easily
with a good client program.  You don't get (as much of) that kind of
spam in forums, depending on the authentication process and the
vigilance of the forum staff/moderators.  I used to subscribe to a bunch
of different Linux and programming-related mailing lists... some of
which could run to several hundred messages per month *each*.  Yeah,
decent filters and storage can mute a lot of that, but not as
effeciently as reading the groups via news.gmane.org which provides a
mail2news gateway for a lot of mailing lists like this one.  I don't
have to receive or store all those messages anymore (most of which I
skim the subject and then mark as read).

That said, the irony that there seems to be a distinct *lack* of GUI 
usenet reader programs for Linux just kills me. Seems like its either Pan, 
or knode if you're into KDE.  Otherwise... you get to go dredge up old
CLI programs like this one (slrn).  Works pretty well (better than I
remember, actually) but still... having to exit the program and restart
it to open a different server is *very* old-school :/


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

Re: OT: usenet reader software

[Martin S]

>From what I've seen so far it's more like your limited standard mail filtering 
>tool. 

IIRC when I used Usenet much gnus on Emacs had much more powerful capabilities. 

/martin s

On 20 Jul 2014, Mark Lawrence  wrote:
>On 19/07/2014 23:38, Sturla Molden wrote:
>>  wrote:
>>
>>> That doesn't address the problem at all! :-)  You still need a news
>>> reader.
>>
>> The problem was that Thunderbird does not support killfiles when used
>as a
>> newsreader. Leafnode adds filtering capabilities which Thunderbird
>> (supposedly) does not have.
>>
>> Sturla
>>
>
>So what does clicking on Message->Create filter from message... do
>exactly?

-- Sent with K-@ Mail - the evolution of emailing.-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: usenet reader software

[Martin S]

>From what I've seen so far it's more like your limited standard mail filtering 
>tool. 

IIRC when I used Usenet much gnus on Emacs had much more powerful capabilities. 

/martin s

On 20 Jul 2014, Mark Lawrence  wrote:

On 19/07/2014 23:38, Sturla Molden wrote:
<

c...@isbd.net> wrote:

That doesn't address the problem at all! :-) You still need a news
reader.


The problem was that Thunderbird does not support killfiles when used as a
newsreader. Leafnode adds filtering capabilities which Thunderbird
(supposedly) does not have.

Sturla



So what does clicking on Message->Create filter from message... do exactly?


-- Sent with K-@ Mail - the evolution of emailing.-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

[C.D. Reimer]

On 7/19/2014 7:03 PM, TP wrote:
I would say that since PyCharm (https://www.jetbrains.com/pycharm/) 
now has a free Community Edition it is an even more notable IDE as the 
above two programs cost $.


PyCharm look really nice as an IDE. Thanks for the heads up.

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

Re: Confused with Functions and decorators

[Jerry lu]

Ok thanks so much i really want to get good. I also found this MIT open course 
lectures for python. Is this good to use as a source of learning? I think it 
would because it is MIT.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused with Functions and decorators

[Chris Angelico]

On Sun, Jul 20, 2014 at 12:24 PM, Jerry lu  wrote:
> ok I seem to very confused about this. Is there like a page or web page that 
> like completely sums this up so i can study. I am going to look up 'functions 
> in python'.

Yep, look up stuff like that. I gave you some keywords to search for
(web search - Google, Bing, Yahoo, whatever you're comfortable with)
in my last email. They'll start you off with some of the important
topics.

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

Re: Confused with Functions and decorators

[Jerry lu]

ok I seem to very confused about this. Is there like a page or web page that 
like completely sums this up so i can study. I am going to look up 'functions 
in python'. I am not sure if this is what we a talking about as a whole here 
but I'am sure that I'll find something. I am all good with decorators just I 
can't wrap my head around why we need a function within a function? like the 
outer and inner thing. for example if we have like:

>>> def multi_squared(func):
   def multi():
 return (func)**2
   return math
>>>
>>>@math #does decorator go here or when we call the function???
>>>def number(x, y):
 return x*y

is this above example valid? like this is the stuff i am stuck on like i know 
what todo or i think i know but not sure if it is perfectly valid. I am going 
to search for something now but if you know where i could find something like 
this or if you could sort it out that would be great.
   
   

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[TP]

On Sat, Jul 19, 2014 at 12:28 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> For Python users, the IDEs from
> Wingware and Activestate are notable:
>
> https://wingware.com/
> http://komodoide.com/
>

I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has
a free Community Edition it is an even more notable IDE as the above two
programs cost $.

And as a Windows user, for version control I really like TortoiseHg (
http://tortoisehg.bitbucket.org/) for Mercurial. Likewise I tend to use
TortoiseSVN and TortoiseGit rather than the command line. PyCharm even has
support for those but I still like right-clicking on folders in Windows
Explorer and activating various hg commands from the popup menu. Especially
since not every program I write is written in Python :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and IDEs [was Re: Python 3 is killing Python]

[C.D. Reimer]

On 7/19/2014 6:23 PM, Steven D'Aprano wrote:
I haven't used Python on Windows much, but when I did use it, I found 
the standard Python interactive interpreter running under cmd.exe to 
be bare- bones but usable for testing short snippets. If I recall 
correctly, it is missing any sort of command history or line editing 
other than backspace, which I guess it would have been painful to use 
for extensive interactive work, but when I started using Python on 
Linux the interactive interpreter had no readline support either so it 
was just like old times :-)


Windows PowerShell supports very basic Linux commands and has a command 
history. I'm always typing "ls" for a directory listing when I'm on a 
Windows machine. The regular command line would throw a DOS fit. 
PowerShell lets me get away with it.


http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands

I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is 
dying and MacBook shuts down after 15 minutes. I'm surprised at how well 
I was able to set up a equivalent programming environment on Windows.


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

Re: What's the proper style for a library string function?

[Steven D'Aprano]

On Sat, 19 Jul 2014 10:38:47 -0700, C.D. Reimer wrote:

> Greetings,
> 
> I typically write a Python 2.7 string function in my library like this:
> 
>  def getCompletedTime(start, end): 
>  return "Time completed:", str(end - start)
> 
> And called it like this:
> 
>  print getCompletedTime(start, end)
> 
> Since every Python script I write is executed from the command line, I
> rewrote the string function like this:
> 
>  def getCompletedTime(start, end): 
>   print "Time completed:", str(end - start)
> 
> And call it like this:
> 
>  getCompletedTime(start, end)

In general, I much prefer the first version. The general principle I 
follow is, as much as possible, to separate calculation from display. 
Advantages include:

- You can easily re-use the getCompletedTime function in situations where 
you don't want to display the time, or pass the result on to another 
function for further processing before display.

- It makes automated testing of the functions much easier.

- It makes it easier to vary the type of display. Today you want to print 
to the standard output. Tomorrow you might want to output to a file, or 
display in a GUI window.

- It makes it easier to understand the large-scale structure of your 
code. Seeing "print getCompletedTime(a, b)" makes it pretty clear that 
you are printing the result of the calculation, whereas 
"getCompletedTime(a, b)" does not.



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

Re: Improving Idle (was Re: Python 3 ...)

[Chris Angelico]

On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson
 wrote:
> Does the IDLE bug-tracker exist to *SOLVE* problems or to
> *PERPETUATE* them?

Definitely the latter. If it weren't for that tracker, bugs would just
quietly die on their own. The PSU has a roster for feeding the bugs,
changing their litter, and all other bug-related duties, and when
someone goes on holidays and forgets to schedule a replacement, heaps
of bugs just inexplicably die. (The PSU generally conceals this faux
pas under the name of a "release".)

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Chris Angelico]

On Sun, Jul 20, 2014 at 11:23 AM, Steven D'Aprano
 wrote:
> If I recall correctly, it [Python under cmd.exe] is
> missing any sort of command history or line editing other than backspace,

Not quite, but it has some extreme oddities. I'd have to call them
features because I can't imagine them to be bugs, but they're very
surprising... like how you can recall something, but if you enter it
without any editing, your "current recall position" is retained. This
means you can re-enter a series of lines by recalling the first and
then pressing Down, Enter for each subsequent line (it's a feature!),
but it means that any usage where the lines are truly independent will
start getting very awkward.

In contrast, Idle recalls entire suites, rather than individual lines,
which (IMO) makes it superior to a readline-based interface.

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

Re: Improving Idle (was Re: Python 3 ...)

[Rick Johnson]

On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 12:29 PM, Rick Johnson wrote:
> [2.7.2 and 3.2.2] are ancient versions from years ago that
> no one should be running Idle on now.

I have just downloaded and installed versions 2.7.8 and
3.4.1, and i am happy to report that both the "HOME_KEY"
*AND* the "CONTROL+LEFT_ARROW" events are working properly
and intuitively. I also would like to give my deepest
gratitude and thanks to those who corrected these
abnormalities!

KEEP UP THE GOOD WORK GUYS!

> To repeat: I agree [that tab indention is bad], Raymond
> Hettigner agrees, everyone seems to agree, and we all have
> for years. http://bugs.python.org/issue7676 is over 4
> years old.  But a patch can only implement a specific new
> behavior, not just 'stop the old'.

Just checked 3.4.1, and it is still using a tab for
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues that i
mentioned, however, i feel it is an important issue to
solve.

To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue -- and as such, a
few basic "rules" of how the IDLE shell "interacts" with a
user is prerequisite.

  1. The shell presents a prompt (in the case of the IDLE
  shell the prompt is ">>> "), as a "starting" point for
  interactive commands.

  2. The user begins typing his command at the prompt...

2a. In the process of typing his command, each time the
user presses the "ENTER" or "RETURN" keys (which i shall
from now on refer to them *singularly* as the: "ER-
KEYS"), the shell "intuits" whether the user intended to
complete his command "at-the-current-line" *OR* that the
user intends to "continue-writing-more-code", on
subsequent lines.

Note: As you can see the actions taken by pressing the
"ER-KEYS" depend on the context in which they where
pressed! If the command is "believed" to be *COMPLETE*,
then the action will be: "evaluate the users command now
and display a result", however, if the command is
"believed" to be *INCOMPLETE*, the action will be:
"allow the user to continue entering his command".

2b. If the "shell" believes that the user is finished
writing his command, the shell will evaluate the
*ENTIRETY* of the command (which could span one or more
lines!) and then display the result of that evaluation
*BENEATH* the command, however, if the shell "believes"
that the user intends to "continue-writing-more-code",
then the shell will allow the user to continue writing
more code.

  STEP[N:]. There is much more to the interaction between
  "shells" and "users", however, these first two steps, and
  their subsequent "sub-steps", are all we need to concern
  ourselves with at this time, in order to solve *THIS*
  particular problem.

Now, between the "shell" and its "user" exists a contract,
and the preceding steps i outlined describe most of thast
contract, however, i realized that i can describe the full
contract more clearly by conflating the "shell" with "god"
and the "user" as some poor disciple. If we view the
contract through "the eyes of a *GODLIKE* shell" it might
read something like:

  And the "shell" so-eth declared:

  Ye shall be presented with a prompt, and from that prompt
  thou shalt humbly enter requests. When i find thouest
  requests pleasing, i shall reward thou with my vast
  knowledge by displaying to you the result utilizing an
  esthetically pleasing shade of blue, HOWEVER, shall i find
  thou request to be illogical or malformed, i shall punish
  thou with furious displays of my rebukes, utilizing the
  "fear color" of *BLOOD* red! And thou shalt know my name
  is the SHELL!

  Furthermore, ye shall not be allowed to edit previous
  request, no matter how blasphemous they may be! No, they
  shall live as a testimate to thouest ignorance, a *PUBLIC*
  testiment for all to see -- until which time thou decideth
  to terminate our contract.

Now that we understand the contract between "shells" and
"users" we can focus in on the problem. The problem
manifests itself when the user wants to write commands that
span *MORE* than one line. For instance, when i write the
first line of a "multi-line source code" like this:

>>> for x in range(10):

And then i press the "enter key", the current IDLE shell is
going to insert a tab char (not good!), when it *SHOULD*
have inserted a "buffer prompt" of some kind, and then
calculated the correct "extrapolation-indentation" (by
adding four to the indent of line #1, which is four!) for
this new line of code.

>>> for x in range(10):
... do_something

Notice the "buffer prompt" of "... ", after which follows
the "extrapolation indent" of "", after which defines
the *BEGINNING* of my next command of "do_something"? Seems
simple enough huh? Oh but, my friend, *NOTHING* is simple in
this damn community is it!

==

Re: What Next After Python Basics

[Chris Angelico]

On Sun, Jul 20, 2014 at 6:26 AM,   wrote:
> But mostly, just code. Anything. For my studies, I get assignments to go 
> through large bodies of text and sort them for some criteria, and while I'm 
> given tools to do it, I try to make my own tools to get the job done. That is 
> to say, if there's something in your day that you use in some way, and it's 
> fairly simple, or its essential functionality can be copied, then that's 
> something to copy.
>
>
> I apologize for the raving suggestions.

No, that's not raving. The way to get good at something is to do it,
and do it a lot. That's why I don't play lasertag, that's why I don't
butcher my own meat, that's why I don't write optimizing C compilers.
I don't have time to get good at any of those things. (Not that I have
a philosophical objection to any. If my circumstances change, I might
take one of them up at some point, but for the moment, I don't.) To
become a programmer, you need to write programs.

As a student programmer, you get very specific tasks: Write a program
that, given this input, produces this output; and use exactly these
tools (language statements, library functions, etc) to do so. There's
a definite "right answer" and a whole lot of "wrong answers". (And
it's really obvious when someone asks for help. When the problem's
that specific, it's bound to be homework.)

As a novice, you generally have fairly specific goals, but now you
have flexibility in how you implement it. Import this CSV file into an
SQL database, converting "25 Mar 01" into "2001-03-25" as it goes
through. You could do that with a preparse script, or you could import
into a temporary table and convert it in the database, or you could
parse and import in one step. It's fairly straight-forward to figure
out whether you've accomplished the goal or made a mess of it, but
there's no longer a "right way to do it".

An expert programmer has to cope with much vaguer requirements. Reduce
the number of data entry errors in invoicing. Adding something to a UI
that helps people notice errors earlier may not clearly and
demonstrably be working, until they've had a chance to get accustomed
to it and you start seeing that the error average per week is lower
than it was before the feature went in. (And even then, you can't be
sure; something else might have caused the improvement.)

(An expert will also sometimes get really clear goals. These are good
days. These are luxuries. These are the times when you profusely thank
the previous programmer for putting in such comprehensive unit tests
that the porting process is reduced to "make sure all tests pass, then
we're done". These are rarities, sadly, but they definitely do exist.)

Before you can handle the complex and less-clear jobs, you have to get
enough experience to know what you're doing. That means doing jobs
that have really clear requirements. Will they be boring? Maybe.
Derivative? Almost certainly. But pointless? Absolutely not. And maybe
you'll recreate something in almost the same way, but with one little
tweak that makes it now absolutely perfect for you. Or recreate
something in a different language, just because it's better that way.
(I did that myself recently - see http://rosuav.com/1/?id=1009 - even
though the old one was working fine.) Never useless, because of what
it does for you, the programmer.

It takes ten thousand hours of practice to achieve competence.
Fortunately, those hours will be enjoyable, if spent programming. :)

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[C.D. Reimer]

On 7/19/2014 5:41 PM, Tim Delaney wrote:
The main thing is that versioning should be automatic now - it's 
almost free, and the benefits are huge because even trivial scripts 
end up evolving.


I keep my modest Python scripts in a Dropbox directory and run a weekly 
Python script to zip up the Dropbox directory for safekeeping on the 
home file server and Microsoft OneDrive. If I really need a recent copy 
of a script, Time Machine on the Mac should have a copy from the Drop 
Box folder.


The only time I use version control is when I have a big project with 
many moving parts and/or I'm publishing software for other people to use.


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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Steven D'Aprano]

On Sat, 19 Jul 2014 14:31:10 -0400, Terry Reedy wrote:

> On 7/19/2014 3:28 AM, Steven D'Aprano wrote:
> 
>> So why does Python ship with IDLE?
> 
> On Windows the Idle shell is needed for sensible interactive use.

One might say that *some* IDE is needed, but Idle itself isn't 
compulsory :-)

It also depends on what you consider sensible.

I haven't used Python on Windows much, but when I did use it, I found the 
standard Python interactive interpreter running under cmd.exe to be bare-
bones but usable for testing short snippets. If I recall correctly, it is 
missing any sort of command history or line editing other than backspace, 
which I guess it would have been painful to use for extensive interactive 
work, but when I started using Python on Linux the interactive 
interpreter had no readline support either so it was just like old 
times :-)


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

Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])

[Chris Angelico]

On Sun, Jul 20, 2014 at 10:41 AM, Tim Delaney
 wrote:
> On 20 July 2014 09:19, Chris Angelico  wrote:
>>
>> That said, though, there are some projects so modest they don't
>> require dedicated repositories. I have a repo called "shed" - it's a
>> collection of random tools that I've put together, no more logical
>> grouping exists.
>
> Agreed. I have a "utils" one - but I do like "shed" and think I'm going to
> rename :)

I first met that name on our old DOS and OS/2 systems, set up by my
Dad. It was a directory on whichever drive was appropriate (exactly
one per installation - we wouldn't risk a network dependency here),
and had programs that would probably go in /usr/bin or /usr/local/bin
on a Unix system. Part of setting up a new OS/2 installation was
always copying E:\SHED (the network drive) to D:\SHED, and putting
D:\SHED\NPSWPS\NPSWPS.EXE into Startup. (NPS WPS Enhancer, awesome
program. If you have OS/2, get it. What, you don't have OS/2 anywhere?
What a surprise.)

Other people had, for instance, a C:\BELFRY (best place to have BATs,
you know), or other such names. What's your favorite
directory/repository name for a concretion of ... random stuff?

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

Re: OT: usenet reader software

[Mark Lawrence]

On 19/07/2014 23:38, Sturla Molden wrote:

 wrote:


That doesn't address the problem at all! :-)  You still need a news
reader.


The problem was that Thunderbird does not support killfiles when used as a
newsreader. Leafnode adds filtering capabilities which Thunderbird
(supposedly) does not have.

Sturla



So what does clicking on Message->Create filter from message... do exactly?

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: What's the proper style for a library string function?

[Chris Angelico]

On Sun, Jul 20, 2014 at 4:40 AM, Wojciech Giel  wrote:
> You might look into PEP8 "Style Guide for Python Code" it will give you
> recommendation how to write a code. among other gives most sensible answer:
>  "Consistency within a project is more important. Consistency within one
> module or function is most important.. When in doubt, use your best
> judgment. Look at other examples and decide what looks best."

But perhaps the most crucial part of PEP 8 is up in the introductory text:

"""
But most importantly: know when to be inconsistent -- sometimes the
style guide just doesn't apply.
...
Some other good reasons to ignore a particular guideline:

1. When applying the guideline would make the code less readable, even
for someone who is used to reading code that follows this PEP.
"""

This is a very New Testament style of guidebook: your conscience is
very important, the details of the rules are subordinate to the
overriding principle of readability. In Dungeons & Dragons terms,
you're called to be a paladin with an emphasis on Good where it
conflicts with Lawful. This is PEP 8's anti-bureaucracy rule.

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Tim Delaney]

On 20 July 2014 09:19, Chris Angelico  wrote:

> On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
>  wrote:
> > IMO there is no project so modest that it doesn't require version
> control.
> > Especially since version control is as simple as:
> >
> > cd project
> > hg init
> > hg add
> > hg commit
>
> That said, though, there are some projects so modest they don't
> require dedicated repositories. I have a repo called "shed" - it's a
> collection of random tools that I've put together, no more logical
> grouping exists.


Agreed. I have a "utils" one - but I do like "shed" and think I'm going to
rename :)

The main thing is that versioning should be automatic now - it's almost
free, and the benefits are huge because even trivial scripts end up
evolving.

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

Re: Python 3 is killing Python

[Terry Reedy]

On 7/19/2014 6:50 PM, Rick Johnson wrote:


[A missed point from my last reply...]

Terry Reedy said:

I believe there is a proposal to be able to clear the
shell window. We just need to add "Clear and restart
shell".



 # In order to prevent confusion with the typical "edit-#
 # undo" of "CONTROL+Z", we should refer to the action of   #
 # "remove the last output displayed" as an "output-undo".  #


That would make implementation easier.


I think IDLE needs all three functionality of:

   1. Reset symbol tables *WHILST* retaining previous "shell
   IO" (Already exists via "Shell->Restart Shell")

   2. Reset symbol tables *AND* clear all "shell IO" (Maybe:
   "Shell->Reset Shell")

   3. Remove the displayed result of the *LAST* command
   processed. (Maybe: "Shell->Remove Last Output")

Hotkeys for all three are a must


I consider them a nicety. We will eventually run out of simple hot keys.


and should be configurable by the user.


I believe anything Idle controls is.


There is also an idea to put help output in an
output window.


In the new issue, I said 'move the last output' from the shell to a 
window, so it would be entirely optional.



I believe more windows just creates more confusion for the
user.


I expect to eventually look at G.Polo's patch for using tabbed 
notebooks, which will help with this.


--
Terry Jan Reedy

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Chris Angelico]

On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney
 wrote:
> IMO there is no project so modest that it doesn't require version control.
> Especially since version control is as simple as:
>
> cd project
> hg init
> hg add
> hg commit

That said, though, there are some projects so modest they don't
require dedicated repositories. I have a repo called "shed" - it's a
collection of random tools that I've put together, no more logical
grouping exists. Generally each one is a single file, although I have
a couple of related ones in there. (Code at
https://github.com/Rosuav/shed if anyone's curious.) If I have an idea
for a program that doesn't really merit a full repo, I'll just save it
into shed. Keeps the "where did I put that, what did I call that" to a
minimum :)

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

Re: Python 3 is killing Python

[Chris Angelico]

On Sun, Jul 20, 2014 at 6:39 AM, Rick Johnson
 wrote:
> To solve this dilemma in *MY* command shell, i use the
> "ALT+UP_ARROW" to delete everything from the "last command
> prompt" to the "end of the text buffer". I think IDLE needs
> both functionality!

Okay, now I understand Rick's attitude. So long as Idle has one single
bug of which he is aware, or lacks one single feature which he can
think of, it is an utter and total embarrassment to the entire Python
community - not just those who work to make Idle what it is, but also
everyone who uses Idle... and everyone who doesn't use Idle, too.

Rick, start writing patches, and stop moaning like this just because
someone hasn't thought of something you've thought of. It may or may
not even be worth implementing this, but definitely you have the wrong
attitude toward feature requests.

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

Re: Python 3 is killing Python

[Chris Angelico]

On Sun, Jul 20, 2014 at 4:00 AM, Ian Kelly  wrote:
> On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico  wrote:
>>> However, a *bare* HOME_KEY press is placing the insertion
>>> cursor *BEHIND* the prompt of the current line. In a shell
>>> environment, you never want to be *BEHIND* the command
>>> prompt.
>>
>> I don't know about the old versions, but in 3.4, it seems to be set so
>> the Home key toggles between the beginning of the code and the
>> beginning of the line. Seems a useful feature, although I can
>> understand if you'd want to disable it and set the Home key to only
>> ever go to the beginning of code. But that's a configuration question;
>> this does not appear to be a bug.
>
> I'd say that moving the cursor to a position where you can't type is a
> bug. In that case, "beginning of the line" should be understood to be
> after the prompt.

You can copy and paste from there. It's functionally equivalent to
being able to press Up arrow and move above the currently-editable
line. But even if it weren't for that, my statement would still be
correct: It's not a bug, and therefore not embarrassment, because it's
a feature that you may or may not like.

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

Re: Python 3 is killing Python

[Rick Johnson]

[A missed point from my last reply...]

Terry Reedy said:
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell".

A command that allows a user to clear the *ENTIRE* "shell
IO" and *ALSO* resets the global and local symbol tables
*WITHOUT* requiring a re-start of the IDLE application,
would be a great addition indeed!

Currently "IDLE shell" has *ONLY* the "Restart Shell"
command, which simply resets the symbol table whilst leaving
all previous "shell IO" untouched. Which is useful in some
situations, but not all...

CONSIDER,

Sometimes you just want to remove the displayed result of
the *LAST* command executed *WHILST* maintaining any
previous displayed "shell IO" -- for instance, in the case
of accidentally printing a *very large* data structure, or a
horrendously untrimmed "dir()" requests.


#DISAMBIGUATION: "EditUndo" vs "OutputUndo"#

# In order to prevent confusion with the typical "edit-#
# undo" of "CONTROL+Z", we should refer to the action of   #
# "remove the last output displayed" as an "output-undo".  #


To solve this dilemma in *MY* command shell, i use the
"ALT+UP_ARROW" to delete everything from the "last command
prompt" up to "the end of the text buffer", in effect,
creating an "output-undo" command without *DEFILING* the
standard semantics of ubiquitous "CONTROL+Z".

I think IDLE needs all three functionality of:

  1. Reset symbol tables *WHILST* retaining previous "shell
  IO" (Already exists via "Shell->Restart Shell")

  2. Reset symbol tables *AND* clear all "shell IO" (Maybe:
  "Shell->Reset Shell")

  3. Remove the displayed result of the *LAST* command
  processed. (Maybe: "Shell->Remove Last Output")

Hotkeys for all three are a must and should be configurable
by the user.

> There is also an idea to put help output in an
> output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but to add additional
"views" to a GUI interface, however, in this case at least,
i believe a menu command (coupled with a keyboard event) is
a best solution to maintain the highest level of "interface
manageability" -- IMHO.

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

Re: OT: usenet reader software

[Sturla Molden]

 wrote:

> That doesn't address the problem at all! :-)  You still need a news
> reader.

The problem was that Thunderbird does not support killfiles when used as a
newsreader. Leafnode adds filtering capabilities which Thunderbird
(supposedly) does not have.

Sturla

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

Re: OT: usenet reader software

[Sturla Molden]

Martin S  wrote:
> Is there a point to still use Usenet? Last time I checked noise
> overwhelmed signal by a factor of something close to 542.

news.gmane.org can be a convinient way to read mailing lists instead of
getting tons of mail.

Sturla

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

Re: What's the proper style for a library string function?

[Wojciech Giel]

On 19/07/14 18:38, C.D. Reimer wrote:

Greetings,

I typically write a Python 2.7 string function in my library like this:

def getCompletedTime(start, end): return "Time completed:", 
str(end - start)


And called it like this:

print getCompletedTime(start, end)

Since every Python script I write is executed from the command line, I 
rewrote the string function like this:


def getCompletedTime(start, end): print "Time completed:", str(end 
- start)


And call it like this:

getCompletedTime(start, end)

The first version is what I'm familiar with having reluctantly learned 
Java at community college, which couldn't afford a Microsoft site 
license for Visual C++ and taught every class in Java. (The Linux 
instructor rebelled against this policy by teaching basic C/C++ and 
shell scripting in his classes.) I recently read an article that 
Python is replacing Java as a teaching language.


The second version is more straight forward but seems less readable 
(i.e., "print getCompletedTime(start, end)" vs. 
"getCompletedTime(start, end)") from the calling script.


Alternatively, I thought about rewriting the string function to accept 
an extra parameter to do either and default to the print statement.


def getCompletedTime(start, end, type = 'p'):
string = "Time completed: " + str(end - start)
if type == 'p':
print string
else:
return string

I'm curious as to what the proper Python style would be for this.
You might look into PEP8 "Style Guide for Python Code" it will give you 
recommendation how to write a code. among other gives most sensible answer:
 "Consistency within a project is more important. Consistency within 
one module or function is most important.. When in doubt, use your 
best judgment. Look at other examples and decide what looks best."


http://legacy.python.org/dev/peps/pep-0008/#function-names

for me if you will be reusing this function I would just use:
 def getCompletedTime(start, end): return "Time completed:", str(end - 
start)


if you need to print just add print, if you want result from this 
function somewhere else you got it. adding additional arguments 
necessary adds complexity. do you really need it. Keep it simple stupid 
expression can be applied everywhere.

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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Tim Delaney]

On 20 July 2014 04:08, C.D. Reimer  wrote:

> On 7/19/2014 12:28 AM, Steven D'Aprano wrote:
>
>> Earlier, I mentioned a considerable number of IDEs which are available
>> for Python, including:
>>
>
> I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors
> with code highlighting can get the job done as well, especially if the
> project is modest and doesn't require version control.
>

IMO there is no project so modest that it doesn't require version control.
Especially since version control is as simple as:

cd project
hg init
hg add
hg commit

FWIW I also don't find a need for an IDE for Python - I'm quite happy using
EditPlus (which I preferred enough to other alternatives on Windows to pay
for many years ago).

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

Improving Idle (was Re: Python 3 ...)

[Terry Reedy]

On 7/19/2014 12:29 PM, Rick Johnson wrote:

On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:


What ancient version, or oddball system are you using? For
me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
the cursor is before the 'a' of [>>> abc]. The HOME key
goes to the same place first, and they before >>> on the
second press (and before 'a' on the third).


On versions 2.7.2 and 3.2.2


These are ancient versions from years ago that no one should be running 
Idle on now.  Before you say another word about Idle, and I mean this 
literally, update to current versions.  There have been about 80 issues 
fixed since 2.7.2 and well more than 100 patches pushed.



CONTROL+LEFT_ARROW is landing *properly* in front of the prompt,


Re-read my comment that you quoted. This has been fixed.


But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!


To repeat: I agree, Raymond Hettigner agrees, everyone seems to agree, 
and we all have for years. http://bugs.python.org/issue7676 is over 4 
years old.  But a patch can only implement a specific new behavior, not 
just 'stop the old'.



I cannot connect [your complaint about IDLE hanging] to
behavior I have seen.


IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:


If you are running your tkinter code in the same process with Idle's 
tkinter code, either with ancient Idle or the '-n' startup option 
(possibly buried in a script), the situation is hopeless.


If you are running your code in a separate process (now the default), 
then, most likely, Idle is not hanging. It is just waiting for your hung 
process. If so, Shell / Restart shell (^F6) will end the user process 
and start a new one.



   1. When running code that results in a Tkinter error.

>

   This can happen when mixing the "grid" and "pack" geometry
   managers within the same "container" widget, which is a
   Tkinter NO-NO, but it can also happen during other Tkinter
   errors!


The user process might hang trying to display a message from *tk*, as 
oppose to Python code, including tkinter. If you start Idle in a console 
window with 'python -m idlelib' or in the console interpreter with 
'import idlelib.idle', you might see messages from tk, as I sometimes do 
(especially with a repository debug build).



   2. During "quickly successive" back-to-back "run sessions"
   of Tkinter GUI apps.

   It seems that sometimes, if you don't give IDLE enough
   time to release resources from the *LAST* run session, it
   will freeze and then throw a "sub-process connection
   failure" message, which, sometimes you can remedy by just
   "trying again", but all to often you are forced to kill
   the entire IDLE (and related sub-) processes.


Use one of the startup options directly above to see if you can get more 
information.  A repeatable or at least semi-repeatable failure case is 
needed to do anything.



However, *EVEN* in the instances where a problem is a direct
result of a "Tkinter NO-NO" (being witting or unwitting),
the user of IDLE should *NEVER* be forced to kill processes


If you are talking about user processes, and we are talking about 
patching Idle, as opposed to Python or the OS (such as Windows), I 
disagree. If you are talking about the Idle process, then yes, I would 
prefer that once Idle starts, it run forever, and recover from any 
problems caused by users. Roger Serwy fixed many Idle shutdowns before 
being swallowed by a PhD program a year ago, but there is more to do.



I believe there is a proposal to be able to clear the
shell window. We just need to add "Clear and restart
shell". There is also an idea to put help output in an
output window. Undo-ing the result of hitting 
seems like a sensible extension of undoing the



So sign the contributor agreement and volunteer to write
and review patches.


In particular, go to
https://www.python.org/psf/contrib
to read *about* the contributor agreement and then go to 
https://www.python.org/psf/contrib-form/
(when the page is working -- it is not at the moment) with Javascript 
turned on to submit on-line (or submit by old-fashioned s-mail). When 
the form is processed, the Contributor Form Received field of your user 
profile at http://bugs.python.org/user12501 will be updated.

Also, please update the email on that page to your current one.

We are much stricter about getting Contributor Agreements than we used 
to be. I will usually not look as non-trivial patches until the author 
has at least signed the agreement and will not commit until it is recorded.



I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide.


On the tracker at least, be polite and ignore impolite posts. I get them 
occasionally.



 NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!


PEP 434 negated some forms of Idle resistance.  However, it did not stop 
resistance in the form of criticism based on how Idl

Re: Python 3 is killing Python

[Rick Johnson]

[A missed point from my last reply...]

Terry Reedy said:
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell".

A command that allows clearing the *entire* shell display
and also resets the global and local symbol tables,
*WITHOUT* requiring a re- start of the entire IDLE
application, would be a great addition!

However, sometimes you just want to remove the displayed
result of the *LAST* command executed --for instance, in
the case of accidentally printing a *very large* data
structure-- and i believe this "output undo action" should
be clearly *DISTINCT* from your normal "edit undo" actions
via: "CONTROL+Z"

To solve this dilemma in *MY* command shell, i use the
"ALT+UP_ARROW" to delete everything from the "last command
prompt" to the "end of the text buffer". I think IDLE needs
both functionality!

> There is also an idea to put help output in an
> output window.

I believe more windows just creates more confusion for the
user. Sometimes you have no choice but add additional
"views", however, in this case at least, i believe a menu
command (coupled with a keyboard event) is the only
solution that can keep the interface "manageable".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What Next After Python Basics

[mathias . moe]

On Sunday, July 13, 2014 10:16:47 PM UTC+2, Orochi wrote:
> Hi,
> I am beginner in Python
> I have Completed Basic Python Course from Codecademy.com .
> Now that I have a hands on the basics what is the next thing I should do.
> I mean should I learn more or start a small Project(Any Ideas are Welcomed) 
> or any Other suggestions.
> Where to Start?
> 
> Thank You,
> Orochi

>
I started up going through a few problems on projecteuler.net, and then 
casually escalated to look through codegolf.stackexchange.com for fun code to 
study, and even some problem to mimic. So, there's *an* idea. (mind you, might 
not be the best of ideas). If you're up for it, there's even rosettacode.org, 
with crazy code which I found fun to study.

But mostly, just code. Anything. For my studies, I get assignments to go 
through large bodies of text and sort them for some criteria, and while I'm 
given tools to do it, I try to make my own tools to get the job done. That is 
to say, if there's something in your day that you use in some way, and it's 
fairly simple, or its essential functionality can be copied, then that's 
something to copy.


I apologize for the raving suggestions.

Mathias H. M.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the proper style for a library string function?

[C.D. Reimer]

On 7/19/2014 12:14 PM, Mark Lawrence wrote:


Is this what you intended?



I'm in the process of generalizing a library module from my first Python 
programming project to make it more accessible to other projects. The 
code I wrote for that project doesn't make sense anymore. As I 
generalize the library module, I'm also cleaning up the calling code 
from that project and other scripts.


The corrected version of the string function should be:

def format_completed_time(start, end):

 return "Time completed: " + str(end - start)

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

Re: What's the proper style for a library string function?

[C.D. Reimer]

On 7/19/2014 11:56 AM, Ian Kelly wrote:

On Sat, Jul 19, 2014 at 12:24 PM, Mark Lawrence  wrote:


Also notice that I changed the function naming style from mixedCase to
lower_case_with_underscores. This is the style recommended for Python
by PEP 8, which you should read if you haven't already.
http://legacy.python.org/dev/peps/pep-0008/#naming-conventions


I love how that section of PEP 8 begins with: "The naming conventions of 
Python's library are a bit of a mess, so we'll never get this completely 
consistent -- nevertheless, here are the currently recommended naming 
standards."


My code is certainly in "a bit of a mess" as I'm still learning Python. 
Following the "Core Python Programming" book for the most part, and 
writing scripts to solve the problems that I'm having. I got an 
associate degree in computer programming but never mastered a 
programming language outside of web development. I'll need to unlearn 
all the bad habits I picked up with PHP over the years.


Chris Reimer


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

Re: What's the proper style for a library string function?

[Mark Lawrence]

On 19/07/2014 18:38, C.D. Reimer wrote:

Greetings,

I typically write a Python 2.7 string function in my library like this:

 def getCompletedTime(start, end): return "Time completed:", str(end
- start)



Further to my earlier post are you aware of the behaviour of your 
"string function"?


>>> def getCompletedTime(start, end): return "Time completed:", str(end 
- start)

...
>>> t = getCompletedTime(0, -1)
>>> type(t)

>>> t[0]
'Time completed:'
>>> t[1]
'-1'

Is this what you intended?

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: What's the proper style for a library string function?

[Ian Kelly]

On Sat, Jul 19, 2014 at 12:52 PM, C.D. Reimer  wrote:
> I've seen code samples for simple functions with the definition and return
> statements written on one line.

Personally, I use this style sometimes for easily understood one-line
if statements or loops. Named functions consist of an interface
declaration and an implementation, and those should be visually
separated by a newline.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the proper style for a library string function?

[Ian Kelly]

On Sat, Jul 19, 2014 at 12:24 PM, Mark Lawrence  wrote:
> Besides that I wouldn't write the function on one line, the first.  Once you
> return your data you can do what you want with it.  The second you can only
> write by default to stdout.  The third is really horrible in my book, YMMV.

I agree. Optional flags that alter the behavior of functions are
considered unpythonic; usually it's better to let the alternative
behavior have its own function, particularly if they can share
implementation.

With that in mind, I would suggest to the OP that you might want to
have *two* functions:

def format_completed_time(start, end):
return "Time completed: " + str(end - start)

def print_completed_time(start, end):
print(get_completed_time(start, end))

Also notice that I changed the function naming style from mixedCase to
lower_case_with_underscores. This is the style recommended for Python
by PEP 8, which you should read if you haven't already.
http://legacy.python.org/dev/peps/pep-0008/#naming-conventions

I also changed the verb from "get" to "format".  "get" suggests to me
that it will retrieve the completed time as a processable value, not
as a part of a formatted string.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the proper style for a library string function?

[C.D. Reimer]

On 7/19/2014 11:24 AM, Mark Lawrence wrote:

Besides that I wouldn't write the function on one line, the first.


I've seen code samples for simple functions with the definition and 
return statements written on one line.



Once you return your data you can do what you want with it.


Returning data from a function is probably the part I'm overlooking.


The third is really horrible in my book, YMMV.


That if/else version was something I've been thinking about doing and 
didn't it put it together until I wrote my email. If I couldn't write a 
better version, I wouldn't keep it myself.


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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[Terry Reedy]

On 7/19/2014 3:28 AM, Steven D'Aprano wrote:


So why does Python ship with IDLE?


On Windows the Idle shell is needed for sensible interactive use. For 
simply editing a Python file, running it, and fixing it, the Idle editor 
seems *about* as good as anything.



It's not because Python requires an
IDE, or that newbies need one, or that there aren't alternatives. The
biggest reason for Python shipping with an IDE is not that people are
unable to install alternatives, but that a lot of people are *prohibited*
from doing so.


This is true, but I think it understates the case.

--
Terry Jan Reedy

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

Re: What's the proper style for a library string function?

[Mark Lawrence]

On 19/07/2014 18:38, C.D. Reimer wrote:

Greetings,

I typically write a Python 2.7 string function in my library like this:

 def getCompletedTime(start, end): return "Time completed:", str(end
- start)

And called it like this:

 print getCompletedTime(start, end)

Since every Python script I write is executed from the command line, I
rewrote the string function like this:

 def getCompletedTime(start, end): print "Time completed:", str(end
- start)

And call it like this:

 getCompletedTime(start, end)

The first version is what I'm familiar with having reluctantly learned
Java at community college, which couldn't afford a Microsoft site
license for Visual C++ and taught every class in Java. (The Linux
instructor rebelled against this policy by teaching basic C/C++ and
shell scripting in his classes.) I recently read an article that Python
is replacing Java as a teaching language.

The second version is more straight forward but seems less readable
(i.e., "print getCompletedTime(start, end)" vs. "getCompletedTime(start,
end)") from the calling script.

Alternatively, I thought about rewriting the string function to accept
an extra parameter to do either and default to the print statement.

 def getCompletedTime(start, end, type = 'p'):
 string = "Time completed: " + str(end - start)
 if type == 'p':
 print string
 else:
 return string

I'm curious as to what the proper Python style would be for this.

Thank you,

Chris Reimer


Besides that I wouldn't write the function on one line, the first.  Once 
you return your data you can do what you want with it.  The second you 
can only write by default to stdout.  The third is really horrible in my 
book, YMMV.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Python and IDEs [was Re: Python 3 is killing Python]

[C.D. Reimer]

On 7/19/2014 12:28 AM, Steven D'Aprano wrote:

Earlier, I mentioned a considerable number of IDEs which are available
for Python, including:


I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors 
with code highlighting can get the job done as well, especially if the 
project is modest and doesn't require version control.


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

Re: Python 3 is killing Python

[Ian Kelly]

On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico  wrote:
>> However, a *bare* HOME_KEY press is placing the insertion
>> cursor *BEHIND* the prompt of the current line. In a shell
>> environment, you never want to be *BEHIND* the command
>> prompt.
>
> I don't know about the old versions, but in 3.4, it seems to be set so
> the Home key toggles between the beginning of the code and the
> beginning of the line. Seems a useful feature, although I can
> understand if you'd want to disable it and set the Home key to only
> ever go to the beginning of code. But that's a configuration question;
> this does not appear to be a bug.

I'd say that moving the cursor to a position where you can't type is a
bug. In that case, "beginning of the line" should be understood to be
after the prompt.

I see the use for it in an editing environment (I have an Emacs macro
that does the same thing), but I don't really see the point of having
the same feature in the shell other than for harmless consistency.
-- 
https://mail.python.org/mailman/listinfo/python-list

What's the proper style for a library string function?

[C.D. Reimer]

Greetings,

I typically write a Python 2.7 string function in my library like this:

def getCompletedTime(start, end): return "Time completed:", str(end 
- start)


And called it like this:

print getCompletedTime(start, end)

Since every Python script I write is executed from the command line, I 
rewrote the string function like this:


def getCompletedTime(start, end): print "Time completed:", str(end 
- start)


And call it like this:

getCompletedTime(start, end)

The first version is what I'm familiar with having reluctantly learned 
Java at community college, which couldn't afford a Microsoft site 
license for Visual C++ and taught every class in Java. (The Linux 
instructor rebelled against this policy by teaching basic C/C++ and 
shell scripting in his classes.) I recently read an article that Python 
is replacing Java as a teaching language.


The second version is more straight forward but seems less readable 
(i.e., "print getCompletedTime(start, end)" vs. "getCompletedTime(start, 
end)") from the calling script.


Alternatively, I thought about rewriting the string function to accept 
an extra parameter to do either and default to the print statement.


def getCompletedTime(start, end, type = 'p'):
string = "Time completed: " + str(end - start)
if type == 'p':
print string
else:
return string

I'm curious as to what the proper Python style would be for this.

Thank you,

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

Re: I am stuck on OOP

[Chris Angelico]

On Sun, Jul 20, 2014 at 2:36 AM, Chris “Kwpolska” Warrick
 wrote:
> On Sat, Jul 19, 2014 at 5:44 PM, Sibylle Koczian  
> wrote:
>> Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick:
>>
>>> Yes, exceptions do exist. But most video tutorials are produced by
>>> people without enough knowledge, and people that should not be working
>>> on educational material. This is especially visible in videos about
>>> basic things: they can be produced by just about anyone with a
>>> microphone — which never leads to anything good. (In order to be more
>>> precise, I'd have to be politically incorrect.)
>>>
>>
>> Moreover people knowing enough about the subject and being able to explain
>> it really well won't necessarily speak clearly. And spoken English is so far
>> away from the written version anyway that it's simply a pain for everybody
>> with another first language.
>
> Depends on the person.  I’m perfectly fine with spoken English (as
> long at it isn’t produced by Asians and other badly-speaking people),
> and it’s not my mother tongue.

My main issue with spoken (as opposed to written) English is that it
becomes so fundamentally linear. You can't skim a podcast and then
read in detail the parts you want; it's fiddly to go back and reread
something; and it's extremely fiddly to go back and re*write*
something, so a lot of errors slip through. (Imagine if you had to
type python-list posts without any cursor movement or backspace
functionality, but you could go back and retype any one paragraph from
scratch. I posit you would leave the odd typo in there, because it's
just not worth the effort of fixing it.) Of course, its linearity is a
feature for a lot of people, who tend to skim things poorly and not
properly learn, but when they're forced to concentrate on what's being
fed to them right this second and not worry about the rest, they can
comprehend it better; but if you can properly grok a wall of text,
that's usually going to be more efficient.

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

Re: I am stuck on OOP

[Chris “Kwpolska” Warrick]

On Sat, Jul 19, 2014 at 5:44 PM, Sibylle Koczian  wrote:
> Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick:
>
>> Yes, exceptions do exist. But most video tutorials are produced by
>> people without enough knowledge, and people that should not be working
>> on educational material. This is especially visible in videos about
>> basic things: they can be produced by just about anyone with a
>> microphone — which never leads to anything good. (In order to be more
>> precise, I'd have to be politically incorrect.)
>>
>
> Moreover people knowing enough about the subject and being able to explain
> it really well won't necessarily speak clearly. And spoken English is so far
> away from the written version anyway that it's simply a pain for everybody
> with another first language.

Depends on the person.  I’m perfectly fine with spoken English (as
long at it isn’t produced by Asians and other badly-speaking people),
and it’s not my mother tongue.

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Chris Angelico]

On Sun, Jul 20, 2014 at 2:29 AM, Rick Johnson
 wrote:
> On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
> *properly* in front of the prompt, so apparently that bug was
> fixed since last i checked, my apologies for being ignorant
> of the situation, but you should understand that i had given
> up after years of no improvements.

Standard rule: Before complaining about something, upgrade to the
latest version - at least the latest bugfix version of that branch.
That would be 2.7.8 and either 3.2.5 or 3.4.1. Complaining about a bug
in an old release is quite pointless if that bug has already been
fixed.

> However, a *bare* HOME_KEY press is placing the insertion
> cursor *BEHIND* the prompt of the current line. In a shell
> environment, you never want to be *BEHIND* the command
> prompt.

I don't know about the old versions, but in 3.4, it seems to be set so
the Home key toggles between the beginning of the code and the
beginning of the line. Seems a useful feature, although I can
understand if you'd want to disable it and set the Home key to only
ever go to the beginning of code. But that's a configuration question;
this does not appear to be a bug.

> But my point is: We *MUST* remove this *excessive*
> indentation width from the IDLE shell!

Why *must*? Is it really that big a problem?

> THERE MUST BE A BETTER SOLUTION!
>
> And this bug is making the whole Python community look like
> a bunch of amateurs!

Frankly, I doubt it. It's pretty obscure. Yes, all bugs should be
fixed where possible, but something of the nature you're describing
does NOT make Python look bad. (Side point: There's nothing bad about
being an amateur. I don't know why so many people think it's an
insulting term.)

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

Re: Python 3 is killing Python

[Rick Johnson]

On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:

> What ancient version, or oddball system are you using? For
> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
> the cursor is before the 'a' of [>>> abc]. The HOME key
> goes to the same place first, and they before >>> on the
> second press (and before 'a' on the third).

On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
*properly* in front of the prompt, so apparently that bug was
fixed since last i checked, my apologies for being ignorant
of the situation, but you should understand that i had given
up after years of no improvements.

However, a *bare* HOME_KEY press is placing the insertion
cursor *BEHIND* the prompt of the current line. In a shell
environment, you never want to be *BEHIND* the command
prompt.

Now, in the case of CONTROL+HOME (which places the insertion
cursor at the very *first* position of the entire text
buffer) and CONTROL+END (which places the insertion cursor
at the very *last* position of the text buffer), we should
leave the default behaviors alone. I don't see any benefit
of changing them.

> "IDLE shell shouldn't use TABs" is a high-priority for me.
> The problem is agreeing on an *exact* specification for
> new behavior, that takes into account both the limitations
> and flexibility of tk. Maybe I should start a thread here
> or python-ideas, where people are willing to discuss
> details.

First, i need to admit that i was wrong when i said: "eight
space indention", since the IDLE shell is using *tabs* for
indention, not spaces! However, a single tab is just as
annoying as 8 spaces

Now, even as much as i dislike tabs, i must admit there is a
benefit to using tabs over spaces, since tabs require only
*ONE* backspace key-press per "pseudo 4 spaces" as compared
to spaces which require a 1:1 ratio of key-presses. Of
course, even this problem can be abstracted away by
"backspace automation code", which the IDLE editor window
already employs!

But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!

> I cannot connect [your complaint about IDLE hanging] to
> behavior I have seen.

IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:

  1. When running code that results in a Tkinter error.
  
  This can happen when mixing the "grid" and "pack" geometry
  managers within the same "container" widget, which is a
  Tkinter NO-NO, but it can also happen during other Tkinter
  errors!
  
  2. During "quickly successive" back-to-back "run sessions"
  of Tkinter GUI apps.
  
  It seems that sometimes, if you don't give IDLE enough
  time to release resources from the *LAST* run session, it
  will freeze and then throw a "sub-process connection
  failure" message, which, sometimes you can remedy by just
  "trying again", but all to often you are forced to kill
  the entire IDLE (and related sub-) processes.
  
  THIS IS EXTREMELY ANNOYING!

However, *EVEN* in the instances where a problem is a direct
result of a "Tkinter NO-NO" (being witting or unwitting),
the user of IDLE should *NEVER* be forced to kill processes
because:

THERE MUST BE A BETTER SOLUTION!   

And this bug is making the whole Python community look like
a bunch of amateurs!

> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell". There is also an idea to put help output in an
> output window. Undo-ing the result of hitting 
> seems like a sensible extension of undoing the

> So sign the contributor agreement and volunteer to write
> and review patches.

I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide. Thank you
Terry for continuing to be a valuable and welcoming resource
for this community! If not for you and a handful of others,
i would have given up on this community a long time ago.

NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!

I will visit the bug tracker again and see if i can provide
some assistance there. Although, the last time i visited, i
remember being annoyed by the tracker interface -- which i
feel is overly noisy and far too complicated. All we need is
a flat list of issues. Is there some method to export
something more "readable"? Or, some sort of documentation?

I must admit, my excitement to help is usually depleted by
the tracker interface before i even have a chance to offer
anything substantial.

If this bug tracker does not improve, i will be forced to
continue posting my grievances here.

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

Re: I am stuck on OOP

[Sibylle Koczian]

Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick:

Yes, exceptions do exist. But most video tutorials are produced by
people without enough knowledge, and people that should not be working
on educational material. This is especially visible in videos about
basic things: they can be produced by just about anyone with a
microphone — which never leads to anything good. (In order to be more
precise, I'd have to be politically incorrect.)



Moreover people knowing enough about the subject and being able to 
explain it really well won't necessarily speak clearly. And spoken 
English is so far away from the written version anyway that it's simply 
a pain for everybody with another first language. Much worse than 
learning Python 3 with a version 2 tutorial or vice versa.


Greetings
Sibylle


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

Creating Windows Start Menu or Desktop shortcuts using setuptools bdist_winst installer

[Yaşar Arabacı]

This is a cross-post from stackoverflow:
http://stackoverflow.com/q/24841130/886669

I am not sure about cross-posting policies of python-list. I am sorry
if this is discouraged.

Here is my problem;

I want to create a start menu or Desktop shortcut for my Python
windows installer package. I am trying to follow
https://docs.python.org/3.4/distutils/builtdist.html#the-postinstallation-script

Here is my script;

import sys

from os.path import dirname, join, expanduser

pyw_executable = sys.executable.replace('python.exe','pythonw.exe')
script_file = join(dirname(pyw_executable), 'Scripts', 'tklsystem-script.py')
w_dir = expanduser(join('~','lsf_files'))

print(sys.argv)

if sys.argv[1] == '-install':
print('Creating Shortcut')
create_shortcut(
target=pyw_executable,
description='A program to work with L-System Equations',
filename='L-System Tool',
arguments=script_file,
workdir=wdir
)

I also specified this script in scripts setup option, as indicated by
aforementioned docs.

Here is the command I use to create my installer;

python setup.py bdist_wininst --install-script tklsystem-post-install.py

After I install my package using created windows installer, I can't
find where my shorcut is created, nor I can confirm whether my script
run or not.

How can I make setuptools generated windows installer to create
desktop or start menu shortcuts?


-- 
http://ysar.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused with Functions and decorators

[Wojciech Giel]

On 19/07/14 12:40, Jerry lu wrote:

oh yeah i forgot about the decorators. Um say that you wanted to decorate a 
function with the outer() func you would just put @outer on top of it? And this 
is the same as passing another func into the outer func?

yes.
syntax was added because with very long function definitions it was 
dificult  to track reassignment to the name when it followed definition 
of the function. decorators is just abbreviation.


>>> def outer(f):
... def inner(*args, **kwargs):
... print("inner function")
... return f(*args, **kwargs)
... return inner
...
>>> @outer
... def myfunc(x):
... print("Myfunc", x)
...
>>> myfunc("test")
inner function
Myfunc test

it is exactly equivalent to:

>>> def outer(f):
... def inner(*args, **kwargs):
... print("inner function")
... return f(*args, **kwargs)
... return inner
...
>>> def myfunc(x):
...  print("Myfunc", x)
...
>>> myfunc = outer(myfunc)
>>> myfunc("test")
inner function
Myfunc test

cheers
Wojciech


and also with the first example you say x is in the scope when is was created 
can you define x in the outer func and refer to it in the inner func?

check nonlocal.

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

Re: Confused with Functions and decorators

[Wojciech Giel]

On 19/07/14 11:52, Jerry lu wrote:

Ok so i am trying to learn this and i do not understand some of it. I also 
tried to searched the web but i couldnt find any answers.

1. I dont understand when i will need to use a function that returns another 
function.
eg
def outer():
  def inner():
x = 5
   return inner
 
  why not just use inner and forget about the whole outer function?
function compositing is one possible use. Functions are first class 
objects so they can be passed as arguments to other functions. in math 
you can define function composition  f(x)  * g(x) by saying that (f * g 
)(x) = f(g(x)).
so composition of two functions gives you a new function with behaviour 
the same as applying fist function to the output of the second.


ex.
you are give two functions f and g to construct their composition:

>>> def outer(f, g):
... def inner(x):
... return f(g(x))
... return inner
...
>>> def f(x):
... print("f ({}) called".format(x))
... return x
...
>>> def g(x):
... print("g ({}) called".format(x))
... return x
...
>>> h = outer(f, g)
>>> h("test")
g (test) called
f (test) called
'test'

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

Re: Confused with Functions and decorators

[Wojciech Giel]

On 19/07/14 11:52, Jerry lu wrote:

Ok so i am trying to learn this and i do not understand some of it. I also 
tried to searched the web but i couldnt find any answers.

1. I dont understand when i will need to use a function that returns another 
function.
eg
def outer():
  def inner():
x = 5
   return inner
 
  why not just use inner and forget about the whole outer function?
function compositing is one possible use. Functions are first class 
objects so they can be passed as arguments to other functions. in math 
you can define function composition  f(x)  * g(x) by saying that (f * g 
)(x) = f(g(x)).
so composition of two functions gives you a new function with behaviour 
the same as applying fist function to the output of the second.


ex.
you are give two functions f and g to construct their composition:

>>> def outer(f, g):
... def inner(x):
... return f(g(x))
... return inner
...
>>> def f(x):
... print("f ({}) called".format(x))
... return x
...
>>> def g(x):
... print("g ({}) called".format(x))
... return x
...
>>> h = outer(f, g)
>>> h("test")
g (test) called
f (test) called
'test'

2. This is more yes or no question when you pass in a func into another func as 
a parameter do you need to specify the parameter that the func is being passed 
into as func?
eg
   def passinto(func)
 pass
 
def param():

  x = 5

 p = passinto(param)


also is this above statement correct?
  


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

Re: Pip doesn't install my scripts

[Yaşar Arabacı]

Hi Chris,

Thanks a lot for your fixes. I have merged your PR and updated PyPi package.

I have one more question; is it documented somewhere that one
shouldn't use dash for stable version names? I am not professional in
programming and I thought for some reason that release numbers should
be separated with dashes.

2014-07-19 12:44 GMT+03:00 Chris “Kwpolska” Warrick :
> On Sat, Jul 19, 2014 at 9:19 AM, Yaşar Arabacı  wrote:
>> Hi,
>>
>> I am trying to package my file, but I am having problems with
>> installing my Scripts. Here is my package:
>> https://github.com/yasar11732/tklsystem
>>
>> Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem
>>
>> The problem I face is that, when I run `python setup.py install` from
>> my development directory, I see that script file is installed.
>> However, if I run `pip install TkLsystem`, my script file is not
>> copied to Scripts directory.
>>
>> What am I doing wrong here?
>>
>> --
>> http://ysar.net/
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
> Tons of things are wrong.
>
> * SyntaxError: Non-ASCII character '\xc5' in file lsystem/__init__.py
> on line 6, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
> * you should not import your package in setup.py
> * you are python 3-only for no real reason at all
> * the zip on PyPI is for version 0.1.3.  It ignores the version 0.1-5,
> because of the dash, which should not be used in names of stable
> software
> * and, most importantly, you’re doing things using ancient methods.
> Upgrade your setup.py to use setuptools, and its entry points
> mechanism.
>
> I’ve sent a PR to fix all of your errors:
> https://github.com/yasar11732/tklsystem/pull/1
>
> --
> Chris “Kwpolska” Warrick 
> PGP: 5EAAEA16
> stop html mail | always bottom-post | only UTF-8 makes sense



-- 
http://ysar.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused with Functions and decorators

[Jerry lu]

Ok thanks man I have never used forums and stuff before but it is great help 
thank you so much.

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

Re: Python-2.6.1 ctypes test cases failing

[nkshirsagar]

libffi fails on cavium for python 2.7 ctypes still doesnt build :(O
On Wednesday, 7 March 2012 11:25:59 UTC-8, Terry Reedy  wrote:
> On 3/7/2012 12:43 PM, Naresh Bhat wrote:
> 
> > Hi All,
> 
> >
> 
> > I have the following setup
> 
> >
> 
> > Kernel version: linux-2.6.32.41
> 
> > Python Version: Python-2.6.1
> 
> > Hardware target: MIPS 64bit
> 
> >
> 
> > I am just trying to run python test cases,  Observed that on my MIPS
> 
> > 64bit system only _ctypes related test cases are failing.
> 
> >
> 
> > Is there any available patch for this issue ??
> 
> 
> 
> There have been patches to ctypes since 2.6.1. At minimum, you should be 
> 
> using the latest version of 2.6. Even better, perhaps, would be the 
> 
> latest version of 2.7, since it contain patches applied after 2.6 went 
> 
> to security fixes only.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

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

Re: Confused with Functions and decorators

[Chris Angelico]

On Sat, Jul 19, 2014 at 9:40 PM, Jerry lu  wrote:
> oh yeah i forgot about the decorators. Um say that you wanted to decorate a 
> function with the outer() func you would just put @outer on top of it? And 
> this is the same as passing another func into the outer func?
>
> and also with the first example you say x is in the scope when is was created 
> can you define x in the outer func and refer to it in the inner func?

Firstly, please don't use Google Groups, or if you must, please clean
up its messes. It's conventional on mailing lists and newsgroups to
quote a bit of text to give context; so, for instance, you mention one
of my examples, without quoting it.

Secondly: Don't worry about decorators. You almost never need them,
and they're very simple. (Python avoids magic whenever it can!) These
two are equivalent:

def inner():
pass
inner = outer(inner)

@outer
def inner():
pass

That's all the decorator does. It's that simple.

As to scoping... read up on closures. There's a lot that I could say,
but you'll find some excellent articles on the internet about it.
Also, you'll learn how to find information, which is a skill you are
going to need in this life :)

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

Re: Confused with Functions and decorators

[Jerry lu]

oh yeah i forgot about the decorators. Um say that you wanted to decorate a 
function with the outer() func you would just put @outer on top of it? And this 
is the same as passing another func into the outer func? 

and also with the first example you say x is in the scope when is was created 
can you define x in the outer func and refer to it in the inner func? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused with Functions and decorators

[Chris Angelico]

On Sat, Jul 19, 2014 at 8:52 PM, Jerry lu  wrote:
> Ok so i am trying to learn this and i do not understand some of it. I also 
> tried to searched the web but i couldnt find any answers.
>
> 1. I dont understand when i will need to use a function that returns another 
> function.
> eg
>def outer():
>  def inner():
>x = 5
>   return inner
>
>  why not just use inner and forget about the whole outer function?
>
> 2. This is more yes or no question when you pass in a func into another func 
> as a parameter do you need to specify the parameter that the func is being 
> passed into as func?
> eg
>   def passinto(func)
> pass
>
>def param():
>  x = 5
>
> p = passinto(param)
>
> also is this above statement correct?

In Python, a function is a real thing, on par with integers, lists,
modules, files, etc. You can create them, dispose of them, pass them
as parameters, receive them as return values, store them in lists,
everything. When you call outer(), it creates a function (which does
nothing useful, and then returns None) and returns a reference to it.
And yes, in that case, there's no particular value in that setup; but
an inner function can be a "closure" (you can look that up later):

def outer(x):
def inner(y):
return x + y
return inner

The x inside inner() will refer to the x that was in scope when it was
created, so you can call outer() several times with different
arguments and get back different functions that do different things.

Since functions are objects of equal standing to any other (called
"first-class" objects - look that up too), you can pass them as
parameters just the same as you would any other type of object.
There's no reason to call an integer 'i', so there's no reason to call
a function 'func'. You can if you like, but it'll work the same
regardless. There is no magic happening here.

None of this has anything to do with decorators, though.

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

Confused with Functions and decorators

[Jerry lu]

Ok so i am trying to learn this and i do not understand some of it. I also 
tried to searched the web but i couldnt find any answers. 

1. I dont understand when i will need to use a function that returns another 
function.
eg
   def outer():
 def inner():
   x = 5 
  return inner

 why not just use inner and forget about the whole outer function?

2. This is more yes or no question when you pass in a func into another func as 
a parameter do you need to specify the parameter that the func is being passed 
into as func? 
eg   
  def passinto(func)
pass

   def param():
 x = 5
   
p = passinto(param)

also is this above statement correct?
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: usenet reader software

[cl]

Sturla Molden  wrote:
> > Guess where I'm going with this is... is there anything out there worth 
> > trying - on Linux - that I'm missing?
> 
> leafnode
> 
That doesn't address the problem at all! :-)  You still need a news
reader.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: usenet reader software

[cl]

memilanuk  wrote:
> 
> Guess where I'm going with this is... is there anything out there worth 
> trying - on Linux - that I'm missing?
> 
If slrn was a maybe then there's also tin for text mode news readers,
it's what I have always used.  I don't know what it does with HTML as
none of the groups I frequent ever have any HTML in them.

It does add one 'GUIness' to its text mode, it's mouse aware so you
can click on messages in a list to open them.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pip doesn't install my scripts

[Chris “Kwpolska” Warrick]

On Sat, Jul 19, 2014 at 9:19 AM, Yaşar Arabacı  wrote:
> Hi,
>
> I am trying to package my file, but I am having problems with
> installing my Scripts. Here is my package:
> https://github.com/yasar11732/tklsystem
>
> Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem
>
> The problem I face is that, when I run `python setup.py install` from
> my development directory, I see that script file is installed.
> However, if I run `pip install TkLsystem`, my script file is not
> copied to Scripts directory.
>
> What am I doing wrong here?
>
> --
> http://ysar.net/
> --
> https://mail.python.org/mailman/listinfo/python-list

Tons of things are wrong.

* SyntaxError: Non-ASCII character '\xc5' in file lsystem/__init__.py
on line 6, but no encoding declared; see
http://python.org/dev/peps/pep-0263/ for details
* you should not import your package in setup.py
* you are python 3-only for no real reason at all
* the zip on PyPI is for version 0.1.3.  It ignores the version 0.1-5,
because of the dash, which should not be used in names of stable
software
* and, most importantly, you’re doing things using ancient methods.
Upgrade your setup.py to use setuptools, and its entry points
mechanism.

I’ve sent a PR to fix all of your errors:
https://github.com/yasar11732/tklsystem/pull/1

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.4.1 64 bit Version

[Chris “Kwpolska” Warrick]

On Sat, Jul 19, 2014 at 1:23 AM, Terry Reedy  wrote:
> On 7/18/2014 2:56 PM, Chris “Kwpolska” Warrick wrote:
>
>> It’s also slightly easier to find pre-made binaries for 32-bit than
>> 64-bit.
>
>
> Searching 'python windows binaries' on Google and the first hit is
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
> "This page provides 32- and 64-bit Windows binaries of many scientific
> open-source extension packages for the official CPython distribution of the
> Python programming language."
>
> He or they are currently compiling both 32 and 64 bits binaries for 2.7,
> 3.3, and 3.4.

I know that site, but its binaries are not used by `pip` while wheels
published on PyPI are — and those wheels are not always available for
64-bit.

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Java

[Scott Dunning]

On Jul 18, 2014, at 8:19 PM, Dan Stromberg  wrote:

> There's comp.lang.java if you have an NNTP feed.
> 
> There are also the OpenJDK mailing lists.
> 
> I had a Java problem once - I'd decided to recode one of my Python
> scripts into Java, just to demonstrate to myself that I could do it.
> I asked about the problem on comp.lang.java, and I got a handful of
> irrelevant responses.  Posting to an OpenJDK list got me a solution
> pretty quickly though.
> 
> The OpenJDK lists are a bit more focused on specific areas of OpenJDK
> than comp.lang.python is; you could end up subscribing to several of
> them to get the same effect.

Thanks Dan!  I checked out the OpenJDK mailing lists they’re a little confusing 
but I’m sure I can find something.  Thanks for the suggestions!


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

Re: OT: usenet reader software

[Marko Rauhamaa]

Chris Angelico :

> On Sat, Jul 19, 2014 at 5:32 PM, Marko Rauhamaa  wrote:
>> Interesting. Who's filtering comp.lang.python?
>
> Possibly your provider, possibly your client, hard to say. But I'm
> pretty confident you do NOT see all the spam that goes through,
> because it's definitely there.

Well, anyway, spam is not a reason to avoid comp.lang.python.


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

Pip doesn't install my scripts

[Yaşar Arabacı]

Hi,

I am trying to package my file, but I am having problems with
installing my Scripts. Here is my package:
https://github.com/yasar11732/tklsystem

Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem

The problem I face is that, when I run `python setup.py install` from
my development directory, I see that script file is installed.
However, if I run `pip install TkLsystem`, my script file is not
copied to Scripts directory.

What am I doing wrong here?

-- 
http://ysar.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: usenet reader software

[Chris Angelico]

On Sat, Jul 19, 2014 at 5:32 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa  wrote:
>>> There's a lot of hot air but I have yet to encounter spam.
>>
>> That means you have good filtering.
>
> Interesting. Who's filtering comp.lang.python?

Possibly your provider, possibly your client, hard to say. But I'm
pretty confident you do NOT see all the spam that goes through,
because it's definitely there.

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

Re: OT: usenet reader software

[Marko Rauhamaa]

Chris Angelico :

> On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa  wrote:
>> There's a lot of hot air but I have yet to encounter spam.
>
> That means you have good filtering.

Interesting. Who's filtering comp.lang.python?


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

Python and IDEs [was Re: Python 3 is killing Python]

[Steven D'Aprano]

Earlier, I mentioned a considerable number of IDEs which are available 
for Python, including:

PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP,
Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, and
BlackAdder.

https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

There is also IDLE, which is part of the standard Python installation, as 
well as my preference: Unix/Linux as an IDE.

http://blog.sanctum.geek.nz/series/unix-as-ide/
http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/


Some people ask:

"How many of those quality IDEs ship with Python?"

Most don't, of course, since they are third-party tools. Not that it 
matters: it's 2014, not 1974, and anyone in the developed world 
interested in computer programming has easy access to the information 
superhighway sometimes know as "the Internet". (Many people in developing 
nations also have access to the Internet, and those who don't probably 
have bigger problems to worry about.) With the Internet, most of these 
IDEs are normally just a few clicks away.

People using Linux will generally find that they can install some of 
these IDEs using their package manager. For example, Red Hat Linux based 
systems such on Centos or Fedora can use the yum package manager, e.g.:

yum install geany geany-plugins

while Debian and Ubuntu based systems (such as Mint) can use apt-get or 
aptitude, e.g.:

aptitude install eric
apt-get install spe

Of course, most Linux distros include a GUI front-end to their package 
manager, but frankly if you're programming on Linux and you're unwilling 
to use the command line, you're making life harder for yourself than it 
need be.

Windows and OS X users, sadly, miss out on the power of an integrated 
package manager. OS X have a couple of third-party packaging systems, 
MacPorts and Homebrew:

http://www.macports.org/
http://brew.sh/

Unfortunately, software development on Windows is something of a ghetto, 
compared to the wide range of free tools available for Linux. Outside of 
a few oases like Microsoft's own commercial development tools, it's hard 
to do development on Windows. Hard, but not impossible, of course, and 
there are quite a few resources available for the Windows user willing to 
download installers from the Internet. For Python users, the IDEs from 
Wingware and Activestate are notable:

https://wingware.com/
http://komodoide.com/


Some people are under the impression that IDEs are mostly or even solely 
for the benefit of "newbies" or "n00bs". That's a gross misunderstanding 
of the situation: the average newbie is likely to be happy writing code 
using Notepad, or whatever bare-bones text editor they're used to, and 
may not even know what an IDE is. It's those with some experience in 
programming (particularly in the Java and Visual Basic worlds) who are 
more likely to expect an IDE.

Another patronising view is that those who are new to programming are 
automatically too incompetent or ignorant to download or install an IDE 
without hand-holding. Even if that were the case, there is no shortage of 
hand-holding available on the Internet, with dozens or hundreds of 
forums, mailing lists, tutorial, videos and blogs offering to help. (It 
is undeniable that the quality of these is *extremely* variable, but 
that's another story.) This is the Internet generation, if software has a 
downloadable installer, or can be installed using a package manager, most 
people can deal with it, and those who can't have many opportunities to 
learn. (It's probably a bit much to expect the average newbie to install 
software from source, especially on Windows which doesn't come with much 
in the way of compilers and other development tools, but still, it has to 
be said that if you're hoping to become a programmer, installing software 
from source is one of the skills you should learn.)

So why does Python ship with IDLE? It's not because Python requires an 
IDE, or that newbies need one, or that there aren't alternatives. The 
biggest reason for Python shipping with an IDE is not that people are 
unable to install alternatives, but that a lot of people are *prohibited* 
from doing so. For those of us who have control over our computing 
environment, it's all too easy to forget that a lot of people (e.g. 
students using school computers, or people in corporate environments 
where the desktops are locked down to a standard operating environment) 
aren't able to install the IDE of their choice. It's relatively easy to 
get Python itself approved -- on many systems, Python comes pre-installed 
-- but trying to get approval to also install third-party software is 
difficult or impossible. It is for the sake of those people, people who 
prefer or require an IDE but don't have the choice to install third-party 
software, that Python ships with a minimal but usable IDE.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/pytho

Re: OT: usenet reader software

[Chris Angelico]

On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sat, Jul 19, 2014 at 4:10 PM, Marko Rauhamaa  wrote:
>>> Martin S :
>>>
 Is there a point to still use Usenet? Last time I checked noise
 overwhelmed signal by a factor of something close to 542.
>>>
>>> Well, here you are at news:comp.lang.python>, in the middle of
>>> all that noise.
>>
>> Or at python-list@python.org - a lot of the newsgroup spam simply
>> doesn't make it across the bridge.
>
> Spam? What spam?
>
> There's a lot of hot air but I have yet to encounter spam.

That means you have good filtering. There are several levels of spam
filtering happening. Fortunately, they do a pretty good job of
catching most of it; I occasionally see junk mail on the list, but
most of it gets caught and discarded.

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