Re: [Tutor] (no subject)

[Cameron Simpson]

Hi, and welcome to the tutor list.

Please try to provide a useful subject line in future posts (not "help", 
perhaps something like "I don't understand this TypeError message").


Anyway, to your question:

On 03Aug2017 13:27, Howard Lawrence <1019sh...@gmail.com> wrote:

hi ! i am newbie to coding love it but need help with problems which i
searched but poor results this is the error: typeError unorderable types:
int() (formerly c...@zip.com.au)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] if __name__=='main' vs entry points: What to teach new comers?

[Cameron Simpson]

On 03Aug2017 00:57, Steven D'Aprano  wrote:

Can you explain the use-case for when somebody might want to use
console_scripts entry points?

I have a module with a main() function and an "if __name__ == ..."
guard. Under what circumstances is that not sufficient, and I would want
console_scripts?


I have a bunch of "one liner" scripts in my personal "bin" directory like this 
one:


   #!/bin/sh
   #
   # Run the named port forwards indefinitely.
   #   - Cameron Simpson  08jul2008
   #
   # Convert to Python module cs.app.portfwd. - cameron, may2017
   #
   exec python3 -m cs.app.portfwd ${1+"$@"}

It relies on the __main__ thing in the cs.app.portfwd module, and many of my 
modules have a main, as I gather do yours.


For a lot of modules that main just runs the selftests, but for some the main 
is a perfectly reasonable command, such as "portfwd" above. So an install 
implies having an invocation script. By hand, I can do the above script.


But if I'm distributing the module via PyPI, how do I install the invocable 
script in the $PATH eg the virtualenv's bin? The installer knows where the 
"bin" is, but on windows the script install is not the same as on UNIX.


So the console_scripts dict provides a mapping from script names to 
module.function callables, and setup installs the right thing. It also 
separates the script name from the module/function names.


Also, modules are groups by function topic. A module may have more than one 
function within it which are suitable command line implementations. The 
console_scripts mapping lets one bind multiple script to suitable entry points.


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] file move with wait period

[Mats Wichmann]

On 08/03/2017 05:22 AM, banda gunda wrote:
> Dear tutors,
> 
> I am interested to move a set of files, periodically, from source_folder to 
> dest_folder.
> source_folder receives processed files from a ‘decompressing program’.  The 
> files are deposited from the ‘decompressing program’ at periodic random 
> intervals.  Furthermore some of the files dropped in the source_folder are 
> large, of typical size 800MB.  These files take time before it is completely 
> deposited in the source_folder.
> 
> I could use shutil.move (source_folder, dest_folder).  But then how?
> 
> The frequency of moving files from source_folder to dest_folder is flexible.  
> It could be once in 15 minutes (or even lengthier).
> Challenge for me:  How could the code include the wait statement to make sure 
> that the file in the source_folder is completely formed before attempting to 
> move to dest_folder?

Well, we cannot answer that question with the information you have given.

"How can you know" is actually the key question to explore. You need to
answer it before you worry about any Pythonic implementation details of
solving your problem.

- is the decompressor initiated by your program?  In that case there
will be techniques to maintain communication with it to find out when it
is done (perhaps as simple as waiting for it to quit-with-success).
- if it launches completely independently, how do you find out that it
has deposited files? Do you intend to just can periodically? Or is there
a way that the system causing the files to be generated can trigger
something that your program could be asked to be notified about when a
file is available?
- is it possible to convice the compressor to give files a certain
suffix or other recognizable pattern, but only when they are complete?
(downloader systems often work like this... while they're writing the
file, it has some temporary name, then when it finishes it is renamed to
the intended target name).

and so on.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[eryk sun]

On Thu, Aug 3, 2017 at 4:22 PM, Chris Warrick  wrote:
>
> Simple: `scripts` are legacy. `entry_points` are the new thing.
> There’s also a third approach: gui_scripts entry_points, which work
> the same way on Linux/*nix, but on Windows, it means that running your
> script by opening the created .exe files does not show a console
> window. Note that stdout/stderr do not work in that mode under
> Windows, which can lead to spurious application crashes.  (GUI-only
> processes cannot use stdout/stderr because they don’t have a console
> attached)

A Windows GUI executable doesn't automatically inherit or create a
console for standard I/O. (It has to manually call AttachConsole or
AllocConsole.) But it does automatically inherit the standard handle
values from the parent process (just the integer values, not the
handles themselves). If these handles are inheritable and the child is
created with handle inheritance, then standard I/O will work. For
example:

C:\Temp>echo spam | pythonw -c print(input()) >out.txt 2>&1
C:\Temp>type out.txt
spam

In the above example pythonw.exe is a GUI executable. The example
reads "spam" from stdin and prints it to stdout, which is redirected
to a file named "out.txt". For those who don't know, `>out.txt` is
shell syntax to redirect stdout to "out.txt", and `2>&1` redirects
stderr (2) to stdout (1).
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] (no subject)

[boB Stepp]

Greetings Howard!

On Thu, Aug 3, 2017 at 3:27 PM, Howard Lawrence <1019sh...@gmail.com> wrote:
> hi ! i am newbie to coding love it but need help with problems which i
> searched but poor results this is the error: typeError unorderable types:
> int() the code in short, number=random.randint(1,20)
> guess=input()
> guess=int(guess)
> but when reach the line that says
> if guess
> i get the error ! help

With the code snippets you've shown in the order you have shown them,
I would not expect you to get this error as it appears that you have
converted the string values from your input statements into integers.
But I suspect that you have not shown the part of the code that is
generating the error.

When posting to this list (Or any other coding list for that matter.)
you should always *copy and paste* into your plain text email the
actual code giving the error.  And then *copy and paste* the FULL
error traceback you receive.  And it does not hurt to give the python
version you are using and the operating system on your machine, too.

At this point I can only guess at things.  Since apparently this is a
number guessing game, you probably have a while loop. Did you use your
variable "guess" in the while statement's condition *before*
converting it to an integer?

Somewhere in your code you are checking that an integer is less than a
string, which is not doable.  The error traceback should tell you what
line number to start looking.

If this does not help then you need to resend your message with your
full code and full traceback unless someone else has better oracle
abilities... ~(:>))



-- 
boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] file move with wait period

[Cameron Simpson]

On 03Aug2017 11:22, banda gunda  wrote:

Dear tutors,

I am interested to move a set of files, periodically, from source_folder to 
dest_folder.
source_folder receives processed files from a ‘decompressing program’.  The 
files are deposited from the ‘decompressing program’ at periodic random 
intervals.  Furthermore some of the files dropped in the source_folder are 
large, of typical size 800MB.  These files take time before it is completely 
deposited in the source_folder.

I could use shutil.move (source_folder, dest_folder).  But then how?


You'd normally use shutil.move(source_file, dest_file) i.e. move individual 
files. Or os.rename, but that requires that the source and dest are the same 
filesystem.



The frequency of moving files from source_folder to dest_folder is flexible.  
It could be once in 15 minutes (or even lengthier).
Challenge for me:  How could the code include the wait statement to make sure 
that the file in the source_folder is completely formed before attempting to 
move to dest_folder?
Thanks in advance for your comments/guidance.


That is the tricky thing; this shows up a lot, also with FTP upload locations 
and so forth.


The problem, as you state, is knowing when the file is complete. There are 2 
basic approaches: do not put a fil into the transfer directory before it is 
complete, or to monitor the files for changes. On the premise that the file 
will be being actively written until it is complete you could keep a list if 
the files in the directory. For each name, record the file's size and 
modification time. Wait for that to be unchanged "long enough"; you might then 
decide it is ready to move.


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] (no subject)

[Howard Lawrence]

hi ! i am newbie to coding love it but need help with problems which i
searched but poor results this is the error: typeError unorderable types:
int()

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Ben Finney]

Thomas Güttler  writes:

> Why are there two ways: "script" vs "console_scripts entry-point"?

Because Distutils implements only ‘scripts’, and that's not capable
enough for what people need so Setuptools implements entry points.

In other words: One of them is in the standard library and does
something; the other is third-party and can do more.

That answers why there are two. But maybe you wanted to ask some
underlying question?

-- 
 \   “It ain't so much the things we don't know that get us in |
  `\trouble. It's the things we know that ain't so.” —Artemus Ward |
_o__) (1834–1867), U.S. journalist |
Ben Finney

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] basic decorator question

[Steven D'Aprano]

Sorry for the delay in responding to this thread!

On Wed, Jul 26, 2017 at 09:22:59PM -0500, boB Stepp wrote:

> I am having a recurring problem with Python:  I can work out the
> mechanics of how various Python constructs work, such as decorators,
> but then I find myself scratching my head as to why would I want to
> use them.  The idea of replacing a function with its decorated version
> sounds cool, but what types of problems would I want to use this
> approach on?

Any time you have a series of functions (or classes) which include the 
same subsection of code, repeated (often word-for-word!), a decorator is 
a possible alternative.

Here's a simple example. You have a bunch of functions which all follow 
the same pattern when called:

- print the function name
- print their arguments
- do some work
- print their return result
- return it

Only the "work" differs. So we could write:


def func1(a, b, c):
print("func1")
print(a, b, c)
result = a + b + c
print("result", result)
return result

def func2(a, b, c):
print("func1")  # Oops, copy-and-paste error!
print(a, b, c)
result = a - b - c
print("result", result)
return result


and so on, but if you have a dozen such functions, that's pretty 
tedious, and the chances of copy-and-paste errors approaches 
certainty. A decorator comes to the rescue!


def decorate(func):
@functools.wraps(func)
def inner(a, b, c):
print(func.__name__)
print(a, b, c)
result = func(a, b, c)
print(result)
return result
return inner

@decorate
def func1(a, b, c):
return a+b+c
   
@decorate
def func2(a, b, c):
return a-b-c


This ensures that all such functions are guaranteed to have the correct 
wrapper code. If you decide to add printing of the date, or change 
printing to logging to a file, you only need to change it in one place, 
not a dozen.


Another use for decorators is to transform the functions in some way. 
That's especially useful for methods, where we have three different 
kinds of methods:

- regular instance methods, which need no transformation because
  they are the default;

- class methods;

- static methods.

Plus you can create your own, if needed. (A fairly advanced topic, but 
less mind-blowing than metaclasses.)

They are all written the same way, with the difference being that class 
and static methods are decorated with the built-in

- classmethod
- staticmethod

decorators, which handle transforming the function objects into 
classmethod or staticmethod descriptors. Don't worry if you don't know 
the technical details of what descriptors are or how they work. The 
point is you don't need to! You just need to call the decorator, and it 
does all the work.


class X(object):
@classmethod
def thingy(cls, arg):
...


Another example is to register a function with something else. If you 
have code where you create functions, then register them, you can 
simplify the process or at least move the registration to the top of the 
function where it is more obvious with a decorator:


def register(func):
MyRegistry.register(func)
return func

@register
def spam():
...


If you need to change the registration details, you change it in one 
place. This is an example that shows that decorators don't need to 
transform their input. In this case, we return the function unchanged.


A more complex example of this is singledispatch:

https://docs.python.org/3/library/functools.html#functools.singledispatch


Memoization (adding a cache) to a function is another good example. 
Instead of re-creating the cache logic in every single function, you 
write it once, as a decorator, and then just call the decorator.

https://docs.python.org/3/library/functools.html#functools.lru_cache



> One thing that bothers me, is that once I decorate the function, I no
> longer have access to the original, un-decorated function.

In the most general case, that is true: the decorator can do anything, 
including deleting the original and replacing it with a function that 
always returns "¿Qué?" no matter the arguments.

Most of the time, this is not a problem. The function is *incomplete* 
until it has been decorated, so you often don't care about the original. 
Do you find yourself worrying that you don't have access to the middle 
one third of your existing functions, without the start and the end? 
Probably not. All that's happened here is that you've systematically 
moved the common bits of your functions into a decorator.

But for those cases where you might care, and since Python 3.2, if you 
use the functools.wraps() helper function (itself a decorator!) to 
create your decorators, it will automatically create a __wrapped__ 
attribute that holds the original, unwrapped function.


> But on the
> other hand, if I had a decorator which I wanted to apply to multiple
> functions, then I would be DRY-er by taking this approach -- I would
> need 

Re: [Tutor] The results of your email commands

[Mats Wichmann]

On 08/03/2017 10:21 AM, Alan Gauld via Tutor wrote:
> On 03/08/17 11:05, Abdur-Rahmaan Janhangeer wrote:
>> me i cooked up :...
> 
> Yes that works too, especially if you don;t need access
> to the individual prices later.
> 
> There are a couple of things to make it more Pythonic...
> 
>> x = True
>> sum = 0
>>
>> while (x==True):
>> a = input("input:")
>> if a =="exit":
>> x=False
> 
> You could replace that with
> 
> sum = 0
> while True:
>  a = input("input:")
>  if a =="exit":
>  break# exit the loop

I'd like to add a thought here... checking for a precise string as a
quit marker is fine, but it might be a little friendlier to accept
spelling variants (as long as none of them could be confused with valid
values... true in this case as you want numbers)... and also to let your
user know what you're expecting!

thus:

a = input("enter number ('exit' when done):)
if a in ('x', 'exit', 'Exit'):

> 
> and
> 
>> try:
>> sum += float(a)
>> except:
>> pass
> 
> That's a risky strategy because if there is
> any error other than the one you anticipate
> then you will never know about it and
> ignore it. You should always try to specify
> the error(s) if possible:
> 
> try:
>sum += float(a)
> except ValueError, TypeError:
>pass
> 

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Chris Warrick]

On 3 August 2017 at 09:52, Thomas Güttler  wrote:
>
>
> Am 02.08.2017 um 18:06 schrieb Wolfgang Maier:
>>
>> On 08/02/2017 04:57 PM, Steven D'Aprano wrote:
>>>
>>> On Wed, Aug 02, 2017 at 10:48:39PM +1000, Ben Finney wrote:

 Thomas Güttler  writes:

> Maybe I am doing something wrong.  I was proud because I did use
> “console_scripts” entry points.


 Did someone lead you to believe it was wrong? Setuptools console_scripts
 entry points are a good tool.

 My point was that it is an *advanced* tool, difficult to use and also
 difficult to explain because the concepts are advanced.
>>>
>>>
>>> Can you explain the use-case for when somebody might want to use
>>> console_scripts entry points?
>>>
>>> I have a module with a main() function and an "if __name__ == ..."
>>> guard. Under what circumstances is that not sufficient, and I would want
>>> console_scripts?
>>>
>>
>> If you install things using pip/setuptools and have defined a
>> console_scripts entry point for it, then the corresponding wrapper
>> script will be installed in whatever is considered the scripts directory
>> at install time on that machine. With a bit of luck the entry point will
>> thus be executable directly without any end-user intervention (like
>> adding folders to $PATH and chmodding files).
>> Personally, I always found it straightforward to write the wrapper
>> script myself, then define this as a 'scripts' file in the package
>> layout of my setup.py, but people's MMV.
>
>
>
> I was not aware of "scripts" in setup.py. But I found docs:
>
>   http://python-packaging.readthedocs.io/en/latest/command-line-scripts.html
>
> Why are there two ways: "script" vs "console_scripts entry-point"?

Simple: `scripts` are legacy. `entry_points` are the new thing.
There’s also a third approach: gui_scripts entry_points, which work
the same way on Linux/*nix, but on Windows, it means that running your
script by opening the created .exe files does not show a console
window. Note that stdout/stderr do not work in that mode under
Windows, which can lead to spurious application crashes.  (GUI-only
processes cannot use stdout/stderr because they don’t have a console
attached)

I’ll take the liberty to link my (better) blog post about this:
https://chriswarrick.com/blog/2014/09/15/python-apps-the-right-way-entry_points-and-scripts/

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] The results of your email commands

[Alan Gauld via Tutor]

On 03/08/17 11:05, Abdur-Rahmaan Janhangeer wrote:
> me i cooked up :...

Yes that works too, especially if you don;t need access
to the individual prices later.

There are a couple of things to make it more Pythonic...

> x = True
> sum = 0
> 
> while (x==True):
> a = input("input:")
> if a =="exit":
> x=False

You could replace that with

sum = 0
while True:
 a = input("input:")
 if a =="exit":
 break# exit the loop

and

> try:
> sum += float(a)
> except:
> pass

That's a risky strategy because if there is
any error other than the one you anticipate
then you will never know about it and
ignore it. You should always try to specify
the error(s) if possible:

try:
   sum += float(a)
except ValueError, TypeError:
   pass

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] file move with wait period

[banda gunda]

Dear tutors,

I am interested to move a set of files, periodically, from source_folder to 
dest_folder.
source_folder receives processed files from a ‘decompressing program’.  The 
files are deposited from the ‘decompressing program’ at periodic random 
intervals.  Furthermore some of the files dropped in the source_folder are 
large, of typical size 800MB.  These files take time before it is completely 
deposited in the source_folder.

I could use shutil.move (source_folder, dest_folder).  But then how?

The frequency of moving files from source_folder to dest_folder is flexible.  
It could be once in 15 minutes (or even lengthier).
Challenge for me:  How could the code include the wait statement to make sure 
that the file in the source_folder is completely formed before attempting to 
move to dest_folder?
Thanks in advance for your comments/guidance.

Best,
Kumar.
+

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Thomas Güttler]

Am 02.08.2017 um 18:06 schrieb Wolfgang Maier:

On 08/02/2017 04:57 PM, Steven D'Aprano wrote:

On Wed, Aug 02, 2017 at 10:48:39PM +1000, Ben Finney wrote:

Thomas Güttler  writes:


Maybe I am doing something wrong.  I was proud because I did use
“console_scripts” entry points.


Did someone lead you to believe it was wrong? Setuptools console_scripts
entry points are a good tool.

My point was that it is an *advanced* tool, difficult to use and also
difficult to explain because the concepts are advanced.


Can you explain the use-case for when somebody might want to use
console_scripts entry points?

I have a module with a main() function and an "if __name__ == ..."
guard. Under what circumstances is that not sufficient, and I would want
console_scripts?



If you install things using pip/setuptools and have defined a
console_scripts entry point for it, then the corresponding wrapper
script will be installed in whatever is considered the scripts directory
at install time on that machine. With a bit of luck the entry point will
thus be executable directly without any end-user intervention (like
adding folders to $PATH and chmodding files).
Personally, I always found it straightforward to write the wrapper
script myself, then define this as a 'scripts' file in the package
layout of my setup.py, but people's MMV.



I was not aware of "scripts" in setup.py. But I found docs:

  http://python-packaging.readthedocs.io/en/latest/command-line-scripts.html

Why are there two ways: "script" vs "console_scripts entry-point"?

Regards,
  Thomas


--
Thomas Guettler http://www.thomas-guettler.de/
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] The results of your email commands

[Abdur-Rahmaan Janhangeer]

me i cooked up :

[warning : see code above better but i did it a bit differently]

x = True
sum = 0

while (x==True):
a = input("input:")
if a =="exit":
x=False
try:
sum += float(a)
except:
pass

print("sum :",sum)

On Thu, Aug 3, 2017 at 3:09 AM, Alan Gauld  wrote:

> I'[ve CCd the list, please use ReplyAll when responding to the list.
>
>
> On 02/08/17 22:13, Borisco Bizaro wrote:
> > Hi,am try to write a code that take input from user continuently
> > until key press it stop and give total amount user  enter.
>
> > while True:
> >   input ("enter another price :")
> > print"\n\n press 0 key to stop"
>
> The last line should probably be before the loop.
>
> You need to store the value somewhere, probably in a list
> of prices.
>
> Also you need to convert the input value to a number, probably
> a float in this case(although for a real system you'd probably
> use a Decimal or a multiplied integer for money.)
>
> You also need to check the value before you store it to see
> if its the last value (ie "0"). Something like
>
> value = input()
> if value == "0": break
> try: prices.append(float(value))
> except ValueError: print "you need a number"
>
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] If tuple cannot be sorted, then why sorted() on a tuple is fine?

[C W]

As pointed out by someone else, ?sorted
sorted(iterable, key=None, reverse=False)

It seems like the only requirement is iterable. I guess tuple is iterable,
so, it doesn't break the assumption that tuple is immutable.

That's what I see, am I right in that?

Thanks!

On Wed, Aug 2, 2017 at 4:07 PM, Alan Gauld via Tutor 
wrote:

> On 02/08/17 20:01, C W wrote:
>
> > I am a little confused about why Tuple can be sorted.
> >
> > Suppose I have the following,
> >
> >> aTuple = (9, 3, 7, 5)
> >> sorted(aTuple)
> > [3, 5, 7, 9]
>
> sorted() returns a new object.
> The original tuple has not been changed
>  - print aTuple to confirm this.
>
> HTH
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor