Guido on python3 for beginners

[Rustom Mody]

On Tuesday, February 16, 2016 at 10:54:43 AM UTC+5:30, John Ladasky wrote:
> On Monday, February 15, 2016 at 6:02:24 PM UTC-8, Rick Johnson wrote:
> > I don't need Python3. And i reckon that by the time i do, 
> > something more interesting will come along, or, i'll create 
> > something more interesting myself. i've been drafting, and 
> > dreaming, of a new language spec for over a year now.. And 
> > the best thing about starting a new language, you can do 
> > anything you want... no dependencies! 
> 
> If you have all the skills that you claim, you're a far better programmer 
> than I.  So -- exactly why are you complaining to people who are developing 
> and/or using Py3?  Go off and impress everyone.  Become your own BDFL.

I hardly want to enter a 'who-can-fart-loudest' contest with Rick...
I hope someone can help me find this link: There is some record that Guido has
said that python3 is probably a bit harder on noobs than python2.

Does anyone know/have that link?
-- 
https://mail.python.org/mailman/listinfo/python-list

Fwd: [python-uk] URGENT: Volunteers for teacher collaboration please... :-)

[Tim Golden]

[Forwarding an email from python-uk in the hope that UK-based
Pythonistas might see it here who don't hang out there...]

From: Nicholas H.Tollervey 
Reply-To: UK Python Users 
To: UK Python Users 

Hi Folks,

I realise I must sound like a stuck record about this sort of thing -
please accept my sincere apologies.

TL;DR: I need volunteers from around the country to support a twilight
meetup of teachers happening in various parts of the UK. It's not
difficult and likely to be a lot of fun and will only take a few hours
of your time in the early evening of a single day. I may be able to
cover travel expenses. Please get in touch. More detail below...

Computing at School (see: http://www.computingatschool.org.uk/), a grass
roots movement of computing teachers in the UK would like to run a
series of training courses for "Master Teachers" in MicroPython on the
BBC micro:bit during March. These teachers would go on to act as the
seed / catalyst for other teachers who require Python training during a
series of training events over the summer. Put simply, this is an
exercise in Python evangelism for teachers.

Master teachers are those who have demonstrated a combination of deep
subject knowledge and teaching skill. Put simply, they're the most
senior teachers you can get. They're also the leaders in the field and
what they say or do influences many hundreds of their colleagues.

The idea is for the master teachers to get together with Python
developers (that'd be *you*) for a few hours to work through MicroPython
related educational resources. These events would happen at university
based hubs around the country. As a Python developer you'll *get a BBC
micro:bit* and be expected to offer advice, answer questions and
demonstrate Python as needed. Honestly, it's not an onerous task and
will only last a few hours in a "twilight" session (i.e. after work).

The locations and proposed dates are as follows:

London: 25th February
Birmingham: 9th March
Nottingham: 15th March
Lancaster: 16th March
Newcastle: 17th March
Hertfordshire: 21st March
Manchester: 23rd March
Southampton: 23rd March

It's easy for UK Python to be very London-centric. This is an
opportunity for Pythonistas throughout the UK to step up and get involved.

Why should you volunteer a few hours of your time to help teachers? Need
you ask? Your help and influence will ultimately contribute to the
education of the next generation of programmers - your future
colleagues. It's a way to give back to the community by fostering the
next generation of Pythonistas with the help of the CAS Master Teachers.
It's also, from a moral point of view, simply a selfless and
unambiguously good thing to do.

If you're thinking "oh, they won't want me", then YOU ARE EXACTLY THE
PERSON WE NEED! Your experience, perspective and knowledge is invaluable
and teachers need to hear from you. Rest assured, this will not be a
difficult or high-pressure activity. In fact, it's likely to be a lot of
fun.

Remember that awesome person who mentored you and/or gave you a step up?
Now's your chance to be that person for a group of master teachers.

If this is of interest to you, please get in touch ASAP and I can start
to coordinate things with CAS.

I'm going to put in a grant request to the PSF to see if we can cover
travel costs for developers. But there's no guarantee this will come about.

Best wishes,

N.



signature.asc
Description: PGP signature
___
python-uk mailing list
python...@python.org
https://mail.python.org/mailman/listinfo/python-uk

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

Re: [python-uk] URGENT: Volunteers for teacher collaboration please... :-)

[Anubhav Yadav]

I met @ntoll at an event in India. It was refreshing to see his passion for
teaching kids about programming and python. I would have loved to be there,
but I don't reside in the UK. Nevertheless, just replying to wish you guys
all the best.



On Wed, Feb 17, 2016 at 2:50 PM, Tim Golden  wrote:

> [Forwarding an email from python-uk in the hope that UK-based
> Pythonistas might see it here who don't hang out there...]
>
> From: Nicholas H.Tollervey 
> Reply-To: UK Python Users 
> To: UK Python Users 
>
> Hi Folks,
>
> I realise I must sound like a stuck record about this sort of thing -
> please accept my sincere apologies.
>
> TL;DR: I need volunteers from around the country to support a twilight
> meetup of teachers happening in various parts of the UK. It's not
> difficult and likely to be a lot of fun and will only take a few hours
> of your time in the early evening of a single day. I may be able to
> cover travel expenses. Please get in touch. More detail below...
>
> Computing at School (see: http://www.computingatschool.org.uk/), a grass
> roots movement of computing teachers in the UK would like to run a
> series of training courses for "Master Teachers" in MicroPython on the
> BBC micro:bit during March. These teachers would go on to act as the
> seed / catalyst for other teachers who require Python training during a
> series of training events over the summer. Put simply, this is an
> exercise in Python evangelism for teachers.
>
> Master teachers are those who have demonstrated a combination of deep
> subject knowledge and teaching skill. Put simply, they're the most
> senior teachers you can get. They're also the leaders in the field and
> what they say or do influences many hundreds of their colleagues.
>
> The idea is for the master teachers to get together with Python
> developers (that'd be *you*) for a few hours to work through MicroPython
> related educational resources. These events would happen at university
> based hubs around the country. As a Python developer you'll *get a BBC
> micro:bit* and be expected to offer advice, answer questions and
> demonstrate Python as needed. Honestly, it's not an onerous task and
> will only last a few hours in a "twilight" session (i.e. after work).
>
> The locations and proposed dates are as follows:
>
> London: 25th February
> Birmingham: 9th March
> Nottingham: 15th March
> Lancaster: 16th March
> Newcastle: 17th March
> Hertfordshire: 21st March
> Manchester: 23rd March
> Southampton: 23rd March
>
> It's easy for UK Python to be very London-centric. This is an
> opportunity for Pythonistas throughout the UK to step up and get involved.
>
> Why should you volunteer a few hours of your time to help teachers? Need
> you ask? Your help and influence will ultimately contribute to the
> education of the next generation of programmers - your future
> colleagues. It's a way to give back to the community by fostering the
> next generation of Pythonistas with the help of the CAS Master Teachers.
> It's also, from a moral point of view, simply a selfless and
> unambiguously good thing to do.
>
> If you're thinking "oh, they won't want me", then YOU ARE EXACTLY THE
> PERSON WE NEED! Your experience, perspective and knowledge is invaluable
> and teachers need to hear from you. Rest assured, this will not be a
> difficult or high-pressure activity. In fact, it's likely to be a lot of
> fun.
>
> Remember that awesome person who mentored you and/or gave you a step up?
> Now's your chance to be that person for a group of master teachers.
>
> If this is of interest to you, please get in touch ASAP and I can start
> to coordinate things with CAS.
>
> I'm going to put in a grant request to the PSF to see if we can cover
> travel costs for developers. But there's no guarantee this will come about.
>
> Best wishes,
>
> N.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


-- 
Regards,
Anubhav Yadav
KPIT Technologies,
Pune.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Oscar Benjamin]

On 16 February 2016 at 19:40, Ben Finney  wrote:
> Oscar Benjamin  writes:
>
>> If you're going to patch open to return a fake file when asked to open
>> fake_file_path why do you care whether there is a real file of that
>> name?
>
> I don't, and have been saying explicitly many times in this thread that
> I do not care whether the file exists. Somehow that is still not clear?


Sorry Ben I misunderstood. I think I can see the source of confusion
which is in your first message:
"""
In some code (e.g. unit tests) I am calling ‘tempfile.mktemp’ to
generate a unique path for a filesystem entry that I *do not want* to
exist on the real filesystem.
"""
I read that as meaning that it was important that the file did not
exist. But you say that you don't care if the file actually exists in
the filesystem or not and just want a unique path.

What do you mean by unique here? The intention of mktemp is that the
path is unique so that there would not exist a file of that name and
if you opened it for writing you wouldn't be interfering with any
existing file. Do you just mean a function that returns a different
value each time it's called? How about this:

count = 0
def unique_path():
global count
count += 1
return os.path.join(tempfile.gettempdir(), str(count))

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

Re: Weird and sparese cgi:error

[Jeremy Leonard]

On Tuesday, February 16, 2016 at 3:02:40 PM UTC-5, Φώντας Λαδοπρακόπουλος wrote:
> Hello,
> 
> I recentely changed VPS server and when i try to load my webiste iam 
> receiving 500 error which i wasnt receiving in my old VPS server with the 
> same exact cgi scripts.
> 
> After looking at Apacher's error_log iam seeing the following output when i 
> try to load scripts from cgi-bin directory.
> 
> 
> [Tue Feb 16 21:28:55.970302 2016] [cgi:error] [pid 17478] [client 
> 180.76.15.28:21311] End of script output before headers: metrites.py
> [Tue Feb 16 21:29:31.193281 2016] [cgi:error] [pid 18802] [client 
> 180.76.15.29:34155] End of script output before headers: metrites.py
> [Tue Feb 16 21:32:21.306627 2016] [cgi:error] [pid 17478] [client 
> 188.138.124.110:40212] End of script output before headers: metrites.py
> [Tue Feb 16 21:37:21.128472 2016] [cgi:error] [pid 19731] [client 
> 204.152.200.42:54376] End of script output before headers: metrites.py
> [Tue Feb 16 21:42:21.198207 2016] [cgi:error] [pid 17478] [client 
> 184.75.210.226:57252] End of script output before headers: metrites.py
> [Tue Feb 16 21:47:21.228361 2016] [cgi:error] [pid 19731] [client 
> 76.72.172.208:34730] End of script output before headers: metrites.py
> [Tue Feb 16 21:52:21.422066 2016] [cgi:error] [pid 18802] [client 
> 85.17.156.11:52071] End of script output before headers: metrites.py
> 
> 
> Please i need your assistance to this.
> thank you.Prob

If you import the cgitb module and then put cgitb.enable() in the first line of 
your code this can help give you more descriptive error messages on the page 
that is producing the errors
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Weird and sparese cgi:error

[Chris Angelico]

On Thu, Feb 18, 2016 at 12:47 AM, Jeremy Leonard  wrote:
> On Tuesday, February 16, 2016 at 3:02:40 PM UTC-5, Φώντας Λαδοπρακόπουλος 
> wrote:
>> Hello,
>>
>> I recentely changed VPS server and when i try to load my webiste iam 
>> receiving 500 error which i wasnt receiving in my old VPS server with the 
>> same exact cgi scripts.
>>
>> After looking at Apacher's error_log iam seeing the following output when i 
>> try to load scripts from cgi-bin directory.
>>
>>
>> [Tue Feb 16 21:28:55.970302 2016] [cgi:error] [pid 17478] [client 
>> 180.76.15.28:21311] End of script output before headers: metrites.py
>> [Tue Feb 16 21:29:31.193281 2016] [cgi:error] [pid 18802] [client 
>> 180.76.15.29:34155] End of script output before headers: metrites.py
>> [Tue Feb 16 21:32:21.306627 2016] [cgi:error] [pid 17478] [client 
>> 188.138.124.110:40212] End of script output before headers: metrites.py
>> [Tue Feb 16 21:37:21.128472 2016] [cgi:error] [pid 19731] [client 
>> 204.152.200.42:54376] End of script output before headers: metrites.py
>> [Tue Feb 16 21:42:21.198207 2016] [cgi:error] [pid 17478] [client 
>> 184.75.210.226:57252] End of script output before headers: metrites.py
>> [Tue Feb 16 21:47:21.228361 2016] [cgi:error] [pid 19731] [client 
>> 76.72.172.208:34730] End of script output before headers: metrites.py
>> [Tue Feb 16 21:52:21.422066 2016] [cgi:error] [pid 18802] [client 
>> 85.17.156.11:52071] End of script output before headers: metrites.py
>>
>>
>> Please i need your assistance to this.
>> thank you.Prob
>
> If you import the cgitb module and then put cgitb.enable() in the first line 
> of your code this can help give you more descriptive error messages on the 
> page that is producing the errors
>

And if that doesn't work, I'd look at the very beginning of code
execution - can the Python interpreter even be found? What happens if
you run one of the scripts from a shell? Maybe there's a shebang
problem.

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

TypeError: not all arguments converted during string formatting

[Ganesh Pal]

Hi Team,


Iam on python 2.6 and Linux  ,  I had replaced print out, err ret with
  logging.info(out, err ,ret)   in the below code . I am getting

"TypeError: not all arguments converted during string formatting"
error any quick suggestion


try:
out, err, ret = run(cmd, timeout=60)
# New line added below
logging.info(out, err ,ret)
if ret != 0:
logging.error("Can't run %s got %s (%d)!" % (cmd, err, ret))
raise Exception("Preparing cluster failed...Exiting !!!")
except Exception as e:
logging.exception("Failed to run %s got %s" % (cmd, e))
sys.exit("Preparing cluster failed")
logging.info("Preparing Cluster.Done !!!")


(Pdb) c
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/logging/__init__.py", line 755, in emit
  File "/usr/local/lib/python2.6/logging/__init__.py", line 637, in format
  File "/usr/local/lib/python2.6/logging/__init__.py", line 425, in format
  File "/usr/local/lib/python2.6/logging/__init__.py", line 295, in getMessage
TypeError: not all arguments converted during string formatting


Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: TypeError: not all arguments converted during string formatting

[Ganesh Pal]

I think  logging.info(out) works the problem is when I add
logging.info(out,err,ret) ,may be there is a better way to supply this
arguments

On Wed, Feb 17, 2016 at 7:28 PM, Ganesh Pal  wrote:
> Hi Team,
>
>
> Iam on python 2.6 and Linux  ,  I had replaced print out, err ret with
>   logging.info(out, err ,ret)   in the below code . I am getting
>
> "TypeError: not all arguments converted during string formatting"
> error any quick suggestion
>
>
> try:
> out, err, ret = run(cmd, timeout=60)
> # New line added below
> logging.info(out, err ,ret)
> if ret != 0:
> logging.error("Can't run %s got %s (%d)!" % (cmd, err, ret))
> raise Exception("Preparing cluster failed...Exiting !!!")
> except Exception as e:
> logging.exception("Failed to run %s got %s" % (cmd, e))
> sys.exit("Preparing cluster failed")
> logging.info("Preparing Cluster.Done !!!")
>
>
> (Pdb) c
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.6/logging/__init__.py", line 755, in emit
>   File "/usr/local/lib/python2.6/logging/__init__.py", line 637, in format
>   File "/usr/local/lib/python2.6/logging/__init__.py", line 425, in format
>   File "/usr/local/lib/python2.6/logging/__init__.py", line 295, in getMessage
> TypeError: not all arguments converted during string formatting
>
>
> Regards,
> Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: TypeError: not all arguments converted during string formatting

[Chris Angelico]

On Thu, Feb 18, 2016 at 12:58 AM, Ganesh Pal  wrote:
> Iam on python 2.6 and Linux  ,  I had replaced print out, err ret with
>   logging.info(out, err ,ret)   in the below code . I am getting
>
> "TypeError: not all arguments converted during string formatting"
> error any quick suggestion
>

The print statement/function happily accepts multiple arguments, and
will join them according to a set of predefined rules. The logging
functions don't have those rules, so they take one message and some
optional parameters. Try this, instead:

logging.info("%r %r %r", out, err, ret)

and then tweak the format string according to requirements. For a
quick dump, this will serve you well.

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

Re: Passing data across callbacks in ThreadPoolExecutor

[Ian Kelly]

On Tue, Feb 16, 2016 at 2:48 PM, Joseph L. Casale
 wrote:
> What is the pattern for chaining execution of tasks with ThreadPoolExecutor?
> Callbacks is not an adequate facility as each task I have will generate new 
> output.

Can you specify in more detail what your use case is?

If you don't mind having threads sitting around waiting, you can just
submit each chained task at the start and have each task wait on the
futures of its dependencies. The advantage of this is that it's easy
to conceptualize the dependency graph of the tasks. The disadvantage
is that it eats up extra threads. You'll probably want to increase the
size of the thread pool to handle the waiting tasks (or use a separate
ThreadPoolExecutor for each chained task).

E.g.:

def task2(input, f1):
f1_result = f1.result()  # Wait for f1 to be done.
result = frobnicate(input, f1_result)
return result

f1 = executor.submit(task1, input)
f2 = executor.submit(task2, input, f1)

f1.add_done_callback(handle_task1_done)
f2.add_done_callback(handle_task2_done)



Otherwise, is there some reason you can't use multiple callbacks, one
to handle the task's output and one to submit the chained task?

E.g.:

def chain_task2(input, f2):
f2 = executor.submit(task2, input, f2.result())
f2.add_done_callback(handle_task2_done)

f1 = executor.submit(task1, input)
f1.add_done_callback(handle_task1_done)
f1.add_done_callback(functools.partial(chain_task2, input))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[Ulli Horlacher]

Thorsten Kampe  wrote:

> By the way: there is a script called `win_add2path.py` in your Python 
> distribution

I have 
"Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC
v.1500 32 bit (Intel)] on win32"
and there is no "win_add2path.py"

But I found another solution:

I need the extended PATH only for cmd.exe: users shall run my program
(a compiled executable) without having to enter the full path.

At startup cmd.exe runs a script which is defined by the registry variable
AutoRun in "HKCU\Software\Microsoft\Command Processor"

I set this variable with:

  rc = "HKCU\Software\Microsoft\Command Processor"
  ar = "%USERPROFILE%\Desktop\autorun.cmd"
  system('reg add "%s" /v AutoRun /d "%s"' % (rc,ar))

and write into autorun.cmd:

set PATH=%PATH%;%USERPROFILE%\Desktop


This command extends PATH only for this cmd.exe instance.
This is all I need!


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horlac...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-68565868
Allmandring 30aFax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: psutil 4.0.0 released - how to get "real" process memory and environ in Python

[Giampaolo Rodola']

Full blog post:
http://grodola.blogspot.com/2016/02/psutil-4-real-process-memory-and-environ.html

-- 
Giampaolo - http://grodola.blogspot.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Reg: Data frame conversion

[Sushanth]

​i need to convert r data fr​ame to pandas dataframe and vise versa



-- 

*Regards*
*Sushanth*
*ph : 91-9444583307*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reg: Data frame conversion

[Tony van der Hoff]

On 17/02/16 18:00, Sushanth wrote:

​i need to convert r data fr​ame to pandas dataframe and vise versa


Wow! How do you plan to do that?

--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |
--
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[eryk sun]

On Wed, Feb 17, 2016 at 11:49 AM, Ulli Horlacher
 wrote:
> At startup cmd.exe runs a script which is defined by the registry variable
> AutoRun in "HKCU\Software\Microsoft\Command Processor"
>
> I set this variable with:
>
>   rc = "HKCU\Software\Microsoft\Command Processor"
>   ar = "%USERPROFILE%\Desktop\autorun.cmd"
>   system('reg add "%s" /v AutoRun /d "%s"' % (rc,ar))
>
> and write into autorun.cmd:
>
> set PATH=%PATH%;%USERPROFILE%\Desktop

The AutoRun command (it's a command line, not a script path) gets run
for every instance of cmd.exe, unless cmd is started with the /D
option. This includes the CRT's system() function. Your batch file
needs to set a sentinel variable such as YOUR_APP_AUTORUN that, if
set, makes the batch file exit without extending PATH if it was
already done.

Also, you can't just overwrite a user's AutoRun command like that. If
a command currently exists, you have to concatenate your command with
the existing command using parentheses and the "&" operator, e.g.
(previous_command) & (your_command). Use winreg for this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Are there any pyvcp experts here?

[Gene Heskett]

Greetings;

I am having difficulty with the resultant gui objects its making that are 
too tall.  They fit in the  except the resultant box is 40 
to 50 pixels too tall, wasting valueable screen real estate, and I 
haven't found a way to give the  a "40" command 
that seems to be acceptable.

I know the list strips attachments, so whoever wants to tackle in, I'll 
put the screen snapshot (one pix is worth 10k words), and the .xml file 
that constructs in on my web page & send the link.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Considering migrating to Python from Visual Basic 6 for engineering applications

[wrong . address . 1]

I am mostly getting positive feedback for Python.

It seems Python is used more for web based applications. Is it equally fine for 
creating stand-alone *.exe's? Can the same code be compiled to run on Linux or 
Android or web-based?

Is it possible to create GUI elements with a good IDE? Can they be defined like 
in Visual Basic with given sizes, fonts, visible/invisible, etc.?

Is it easy to do matrix operations in Python? Or do I need to write subroutines 
like in Visual Basic?

Could someone kindly tell me advantages and disadvantages of Python? Or any 
better options? I have like 40-50 VB Forms and may be around 2 lines of 
code. It will be a task to learn a new language and translate/re-write that 
code.

Thanks for your responses. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[sohcahtoa82]

On Wednesday, February 17, 2016 at 11:49:44 AM UTC-8, wrong.a...@gmail.com 
wrote:
> I am mostly getting positive feedback for Python.

Good!

> 
> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?


Python is not traditionally compiled.  It is interpreted.  That said, there are 
utilities out there than can compile a Python script to a Windows executable.  
I personally have never used them, so I don't know about their limitations.

As for Android, I've heard of frameworks for making Android apps with Python, 
but I don't know of any off the top of my head.

> 
> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?

I'm fairly certain there are GUI editors for Python.  I don't use any because I 
don't write anything with a GUI.

> 
> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Check out the numpy and scipy packages.

> 
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.

IMO, Python's greatest advantage is readability.  Python's syntax just plain 
makes sense to me.  It is just an easy language to work with.  It's funny, 
really.  I used to be a hardcore C/C++ fanatic.  When I first started learning 
Python, I hated it.  I thought it made things too easy and held your hand too 
much.  Now, I love it because it makes things so easy and holds your hand.  I 
spend less time worrying about memory allocation and pointer syntax and more 
time actually getting things done.

I think Python's biggest disadvantage is performance.  If you write 100% pure 
Python code, it can be a bit on the slower side.  However, if you're doing 
heavy number crunching using numpy/scipy, they're mostly written in C and are 
quite fast.

Basically, the way I see it, if speed of development is much more important 
than speed of execution, typically Python is a good choice.

> 
> Thanks for your responses.

I'm hoping someone else will be able to give a better response to Python on 
Android and the GUI editor.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[Ulli Horlacher]

eryk sun  wrote:

> > At startup cmd.exe runs a script which is defined by the registry variable
> > AutoRun in "HKCU\Software\Microsoft\Command Processor"
> >
> > I set this variable with:
> >
> >   rc = "HKCU\Software\Microsoft\Command Processor"
> >   ar = "%USERPROFILE%\Desktop\autorun.cmd"
> >   system('reg add "%s" /v AutoRun /d "%s"' % (rc,ar))
> >
> > and write into autorun.cmd:
> >
> > set PATH=%PATH%;%USERPROFILE%\Desktop
> 
> The AutoRun command (it's a command line, not a script path)

A script path is a legal command line, too.


> gets run for every instance of cmd.exe

Yes, this is the intended trick!


> Your batch file needs to set a sentinel variable such as YOUR_APP_AUTORUN
> that, if set, makes the batch file exit without extending PATH if it was
> already done.

Having "%USERPROFILE%\Desktop" twice in PATH is not a problem.


> Also, you can't just overwrite a user's AutoRun command like that. If
> a command currently exists, you have to concatenate your command with
> the existing command using parentheses and the "&" operator, e.g.
> (previous_command) & (your_command).

Good hint, thanks!


> Use winreg for this.

system("reg ...") works for me and is easier :-)

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horlac...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-68565868
Allmandring 30aFax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reg: Data frame conversion

[Mark Lawrence]

On 17/02/2016 18:00, Sushanth wrote:

​i need to convert r data fr​ame to pandas dataframe and vise versa



It is very easy, just write some code.  When you have finished, please 
show us your results.


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

Mark Lawrence

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

Python 3 in 2016

[Mark Lawrence]

rr eat your heart out.

https://hynek.me/articles/python3-2016/

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

Mark Lawrence

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

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Rob Gaddi]

wrong.addres...@gmail.com wrote:

> I am mostly getting positive feedback for Python.

Welcome to the party.  Learn to write Python 3.  There is no reason
whatsoever for someone picking up Python to learn the deprecated
problems of Python 2.

> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?

Standalone EXEs are hit and miss.  I've had best luck deploying just as
Python scripts to machines with an expectation that the environment is
already configured (i.e. Python already installed).

You don't compile, you interpret.  So long as you've got the
interpreter on the target platform you're set.  The EXE tools out there
do so by bundling your plain-text source up with the interpreter
environment.

Packaging/distribution remains one of the real pain points in Python.

> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
>

Yep, and you've got your choice of GUI toolkits (which has ups and
downs).  Coming from VB you're probably used to graphical designers, in
which case I'd point you to Qt Designer and PySide or PyQt.

> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Here's where Python's a godsend.  NumPy will give you vectors, matrices,
linear algebra, all manner of good stuff, all compiled to be blindingly
fast.

Depending on what you mean by engineering applications there's a
ton of good stuff in SciPy too; as an EE I make pretty extensive use
of SciPy's signal processing and optimization packages. Matplotlib is
the 3rd piece of the puzzle and behold! you have graphs, as simple or
complex as you'd like.

> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.
>

It will be, and I'm not sure I'd recommend doing it.  The last time I
wrote any VB was Windows 3.1, and the .NET framework wasn't even a gleam
in Paul Allen's ey.  So I can't speak too authoratively on what you're
leaving. But over the years I've probably tried to get work done in
two dozen languages. None of them turn out correct code more quickly
than Python; few even come close.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reg: Data frame conversion

[Rob Gaddi]

Sushanth wrote:

> ​i need to convert r data fr​ame to pandas dataframe and vise versa
>

Now, now, let's at least _try_ to help.

http://lmgtfy.com/?q=convert+r+data+frame+to+pandas

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[Ray Cote]

On Wed, Feb 17, 2016 at 3:54 PM, Rob Gaddi <
rgaddi@highlandtechnology.invalid> wrote:

> > It seems Python is used more for web based applications. Is it equally
> fine for creating stand-alone *.exe's? Can the same code be compiled to run
> on Linux or Android or web-based?
>
> Standalone EXEs are hit and miss.  I've had best luck deploying just as
> Python scripts to machines with an expectation that the environment is
> already configured (i.e. Python already installed).
>
> You don't compile, you interpret.  So long as you've got the
> interpreter on the target platform you're set.  The EXE tools out there
> do so by bundling your plain-text source up with the interpreter
> environment.
>
> Packaging/distribution remains one of the real pain points in Python.
>

Python is used for much more then web based applications.
The latest versions of pyInstaller (http://www.pyinstaller.org) are
incredibly good at generating single-file binaries for both Windows and
Linux.
We’re using pyInstaller to distribute applications based on some fairly
complex frameworks—including wxPython (http://www.wxpython.org)
which is one option for building GUI applications.

—Ray




-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[eryk sun]

On Wed, Feb 17, 2016 at 2:29 PM, Ulli Horlacher
 wrote:
> eryk sun  wrote:
>> >
>> > set PATH=%PATH%;%USERPROFILE%\Desktop
>>
>> The AutoRun command (it's a command line, not a script path)
>
> A script path is a legal command line, too.

If the registry value were just a script path, you'd have to modify
your script to chain to the previous script, if any. Since it's a
command line you can simply use the & operator to append another
command.

>> gets run for every instance of cmd.exe
>
> Yes, this is the intended trick!

Do you really intend for your batch file to be run every time cmd.exe
is executed, including every time that every program on the machine
calls the CRT system() function?

Why don't you just install a shortcut to a batch file that starts a
command prompt with the extended PATH?

>> Also, you can't just overwrite a user's AutoRun command like that. If
>> a command currently exists, you have to concatenate your command with
>> the existing command using parentheses and the "&" operator, e.g.
>> (previous_command) & (your_command).
>
> Good hint, thanks!
>
>> Use winreg for this.
>
> system("reg ...") works for me and is easier :-)

system('reg...') won't be able to do that unless you export the key to
a .reg file and parse the existing AutoRun value. It would be simpler
to use subprocess.check_output('reg query ...'), but simpler still and
more reliable to just call QueryValueEx.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[paul . hermeneutic]

On Wed, Feb 17, 2016 at 12:49 PM,   wrote:
> Could someone kindly tell me advantages and disadvantages of Python? Or any 
> better options? I have like 40-50 VB Forms and may be around 2 lines of 
> code. It will be a task to learn a new language and translate/re-write that 
> code.

Why are you looking to change from VB? Too slow? Cannot run on
anything but Windows? Buggy?

I, like most people here, would encourage you to learn Python 3.
However, there is something to be said for "if it ain't broke, don't
fix it."
-- 
https://mail.python.org/mailman/listinfo/python-list

How the heck does async/await work in Python 3.5

[Mark Lawrence]

Seeing there is a lot of interest in asyncio recently I figured people 
might be interested in this 
http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5


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

Mark Lawrence

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

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

[William Ray Wing]

> On Feb 17, 2016, at 2:49 PM, wrong.addres...@gmail.com wrote:
> 
> I am mostly getting positive feedback for Python.
> 

I would be surprised if you weren’t.

> It seems Python is used more for web based applications. Is it equally fine 
> for creating stand-alone *.exe's? Can the same code be compiled to run on 
> Linux or Android or web-based?
> 

I’m not sure where you got that idea.  Python has been and is being used for an 
extremely broad range of applications.  At one extreme, the popular YouTube 
site is based on Python (and yes, that is a web application), at the other 
extreme much (most?) of the data analysis of the recent LIGO data leading up to 
the discovery of gravitational waves was done in Python, and numpy (a python 
numerical library); with the results displayed in matplotlib (a python library 
for scientific-engineering graphics).

The basic python language and its libraries are completely cross-platform 
(Linux, OS-X, Windows, iOS, and Android).  The same source code will run on all 
of them.  However, because it is an Interpreted language, the step to a 
bundled, self-contained image is platform dependent. There python compliers (as 
opposed to interpreters) for some, but not all platforms, and there is a very 
active JiT compiler project that would fall somewhere in between. 

> Is it possible to create GUI elements with a good IDE? Can they be defined 
> like in Visual Basic with given sizes, fonts, visible/invisible, etc.?
> 

There are several GUI libraries for Python.  You might check out TK (which 
comes built-in), but there are also libraries like wxPython, Kivi (which is 
completely cross platform), and PyQt.  Note that these are the GUI libraries 
themselves, not IDE’s which tend to be independent.  There are too many IDE’s 
to list here - check with Google.

> Is it easy to do matrix operations in Python? Or do I need to write 
> subroutines like in Visual Basic?

Matrix (and similar operations) can be done in Python directly, but if you need 
maximum performance you should use the optimized vector routines available in 
numpy, these are typically pre-compiled with C or FORTRAN and squeeze out the 
maximum speed your hardware is capable of.  (There is work being done to 
migrate them to GPUs, but is VERY hardware dependent at this point.) If you 
need to do scientific/engineering analysis, you should also check out scipy, 
which is built on top of it and is also vector optimized.

> 
> Could someone kindly tell me advantages and disadvantages of Python?

If you are completely satisfied with VB, there is no reason to change (other 
than the enjoyable exercise of learning a new and more powerful language).

On the other hand, Python has often been referred to as “executable pseudo 
code” - in other words, the english-like steps you might sketch out to outline 
the solution to a programming problem in another language is to all intents and 
purposes Python itself.  This makes for very fast and productive code 
generation with typically fewer errors than are made in other languages. In 
addition, and as has been implied above, it is cross platform.  The same python 
source code (with the appropriate libraries) will run on all the platforms 
mentioned above. One of the biggest productive features of Python is the fact 
that it is interpreted (in its most common instantiation).  Thus, you can have 
two windows open side by side, with the source code in one and running code in 
the other.  Changes in the source code can instantly be reflected in the output.

> Or any better options? I have like 40-50 VB Forms and may be around 2 
> lines of code. It will be a task to learn a new language and 
> translate/re-write that code.
> 

Not necessarily better, but at least worth looking into would be the Swift 
language, which shares much of Python’s modern structure, is now also open 
source, and has been ported to most flavors of Linux.  A Window’s port is 
promised, but I don’t know how far along it is.  It *is* a compiled language, 
so you would then be back in the edit, compile, link, and run loop as you debug 
your code.

I’m sure you will get lots of other answers - Google each of the things I’ve 
mentioned and you will get a truck-load of info.  You might start with 
Wikipedia and read there about Python and Swift.

> Thanks for your responses. 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: extending PATH on Windows?

[Ulli Horlacher]

eryk sun  wrote:

> >> The AutoRun command (it's a command line, not a script path)
> >
> > A script path is a legal command line, too.
> 
> If the registry value were just a script path, you'd have to modify
> your script to chain to the previous script, if any. Since it's a
> command line you can simply use the & operator to append another
> command.

This is the better way, no question. I will change it.


> Do you really intend for your batch file to be run every time cmd.exe
> is executed, including every time that every program on the machine
> calls the CRT system() function?

Yes. It just extends PATH, it should not do any harm.


> Why don't you just install a shortcut to a batch file that starts a
> command prompt with the extended PATH?

Hmm... how does a user starts this shortcut, when it is not found in PATH?


> system('reg...') won't be able to do that unless you export the key to
> a .reg file and parse the existing AutoRun value. It would be simpler
> to use subprocess.check_output('reg query ...')

I do it this way, already.


> but simpler still and more reliable to just call QueryValueEx.

I find it more complicated.

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horlac...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-68565868
Allmandring 30aFax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Will file be closed automatically in a "for ... in open..." statement?

[jfong]

The "for ... open ..." is definitely not a good design pattern. It opens a file 
at "for" block but leaves it closed somewhere in the sky.

> The garbage collector will:
> - reclaim the memory used by the object;
> - close the file. 

I suppose (IMO) that the primitive idea of garbage collection doing the 
file-close affair is to make itself a final defense to prevent the possible 
disaster. (after all it's not of his business:-) But some coding may abuse this 
advantage and forget its hidden danger.

It's better to drop this "for...open..." style completely and stick at "with".

Thanks for all you gurus clarify my puzzle. I deeply appreciated it.

--Jach

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

Re: Will file be closed automatically in a "for ... in open..." statement?

[Mark Lawrence]

On 18/02/2016 01:29, jf...@ms4.hinet.net wrote:

The "for ... open ..." is definitely not a good design pattern. It opens a file at 
"for" block but leaves it closed somewhere in the sky.



Hardly, as all ready explained, but how about this

handle = open('foo.txt')
for line in handle :
...do something...
handle.close()

Is that better?

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

Mark Lawrence

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

Re: Will file be closed automatically in a "for ... in open..." statement?

[Cameron Simpson]

On 18Feb2016 02:05, Mark Lawrence  wrote:

On 18/02/2016 01:29, jf...@ms4.hinet.net wrote:

The "for ... open ..." is definitely not a good design pattern. It opens a file at 
"for" block but leaves it closed somewhere in the sky.



Hardly, as all ready explained, but how about this

handle = open('foo.txt')
for line in handle :
   ...do something...
handle.close()

Is that better?


As already discussed in this thread, not in the face of an exception inside the 
loop or some other change of flow control (early "return" statement etc).


I'm pretty sure jfong understands the issues now, certainly enough to make 
his/her own decisions on the benefits and risks of with versus "for ... open" 
and similar variants.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Will file be closed automatically in a "for ... in open..." statement?

[Tim Chase]

On 2016-02-17 16:51, Steven D'Aprano wrote:
> If you want the file to be closed immediately, you must:
> 
> - use a with statement;
> 
> - or explicitly call f.close()

I have a lot of pre-"with" code (i.e., Py2.4) that looks like

  f = open(...)
  try:
do_stuff()
  finally:
f.close()

To explicitly close() correctly, you still have to pay the
one-level-of-indent cost regardless of whether you use a "with" or
close()

Now that we have the "with" statement, it's the same cost, with no
lost functionality, but with fewer lines of messy code.

So use the "with" unless you're sadly maintaining 2.4 code like
me. :-)

-tkc



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

Re: asyncio - run coroutine in the background

[Paul Rubin]

Marko Rauhamaa  writes:
> @asyncio.coroutine
> def background_task(): ...
> while time.time() - t < 10:
> pass

Wait, that's a cpu-busy loop, you can't do that in cooperative
multitasking.  Of course you need a wait there.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python keyword args can be any string

[Steven D'Aprano]

Today I learned that **kwargs style keyword arguments can be any string:


py> def test(**kw):
... print(kw)
... 
py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
py> test(**kwargs)
{'': 23, '123': 17, '---': 999, 'abc-def': 42}


Bug or feature?



-- 
Steve

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

Re: Python keyword args can be any string

[Chris Angelico]

On Thu, Feb 18, 2016 at 4:42 PM, Steven D'Aprano
 wrote:
> Today I learned that **kwargs style keyword arguments can be any string:
>
>
> py> def test(**kw):
> ... print(kw)
> ...
> py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
> py> test(**kwargs)
> {'': 23, '123': 17, '---': 999, 'abc-def': 42}
>
>
> Bug or feature?

Probably neither. It's something that can't hurt, so there's no point
specifically blocking it. You can do the same thing with other
dictionaries:

>>> globals()["abc-def"] = 42
>>> dir()
['__builtins__', '__doc__', '__loader__', '__name__', '__package__',
'__spec__', 'abc-def']
>>> class Blob: pass
...
>>> b = Blob()
>>> b.__dict__[""] = 23
>>> dir(b)
['', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__gt__',
'__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']

I suppose it's possible for this to be a vulnerability, eg if you
build up an XML node using keyword arguments for attributes, and end
up accepting something with a space in it. But most of the time, the
only consequence is that you use a dict to create a situation that can
only be handled with another dict. Doesn't seem worth the hassle of
preventing it, but I would also see this as a bizarre thing to
deliberately exploit.

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

Re: Python keyword args can be any string

[Ben Finney]

Steven D'Aprano  writes:

> Today I learned that **kwargs style keyword arguments can be any string:
>
>
> py> def test(**kw):
> ... print(kw)
> ... 
> py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
> py> test(**kwargs)
> {'': 23, '123': 17, '---': 999, 'abc-def': 42}
>
>
> Bug or feature?

Incidental feature, I think.

If the caller is deliberately unpacking a dict, it's on them to ensure
the keys are valid identifiers or wear the consequences.

If the function cares so little about the keys in its kwargs that (as in
your example) any string will do for each key, then it's a consenting
actor IMO.

The times when it's a problem – i.e. that the function is trying to use
items from that dictionary as name bindings – the errors will be raised
to the caller that unpacked that mapping. That's where the errors belong.

-- 
 \  “There's a fine line between fishing and standing on the shore |
  `\looking like an idiot.” —Steven Wright |
_o__)  |
Ben Finney

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

Re: asyncio - run coroutine in the background

[Marko Rauhamaa]

Paul Rubin :

> Marko Rauhamaa  writes:
>> @asyncio.coroutine
>> def background_task(): ...
>> while time.time() - t < 10:
>> pass
>
> Wait, that's a cpu-busy loop, you can't do that in cooperative
> multitasking.  Of course you need a wait there.

That was the very point: to demonstrate that coroutines monopolize the
CPU.


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

Re: Python keyword args can be any string

[Terry Reedy]

On 2/18/2016 12:59 AM, Ben Finney wrote:

Steven D'Aprano  writes:


Today I learned that **kwargs style keyword arguments can be any string:


py> def test(**kw):
... print(kw)
...
py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
py> test(**kwargs)
{'': 23, '123': 17, '---': 999, 'abc-def': 42}


Bug or feature?


Incidental feature, I think.


The was discussed on pydev some years ago.  Guido says leave as is. This 
and similar cases of allowing non-identifier is string-dicts does not 
seem to cause a problem and apparently has a few rare legitimate  usages.



If the caller is deliberately unpacking a dict, it's on them to ensure
the keys are valid identifiers or wear the consequences.

If the function cares so little about the keys in its kwargs that (as in
your example) any string will do for each key, then it's a consenting
actor IMO.

The times when it's a problem – i.e. that the function is trying to use
items from that dictionary as name bindings – the errors will be raised
to the caller that unpacked that mapping. That's where the errors belong.




--
Terry Jan Reedy


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

Re: Guido on python3 for beginners

[Steven D'Aprano]

On Wednesday 17 February 2016 19:51, Rustom Mody wrote:

> I hope someone can help me find this link: There is some record that Guido
> has said that python3 is probably a bit harder on noobs than python2.
> 
> Does anyone know/have that link?


I can't say that I've seen it. I know that Raymond Hettinger is not too fond 
of adding new syntactic features that add little in the way of power but 
make the language harder to learn, but I don't recall anyone saying that it 
is harder for newbies to get started with Python 3 than Python 2.

There are more features in Python 3, so in that trivial sense of "more to 
learn", I suppose that it is objectively correct that it is harder to learn 
than Python 2. But I don't think the learning curve is any steeper. If 
anything, the learning curve is ever-so-slightly less steep.


-- 
Steve

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

Re: Guido on python3 for beginners

[Ben Finney]

Steven D'Aprano  writes:

> There are more features in Python 3, so in that trivial sense of "more to 
> learn", I suppose that it is objectively correct that it is harder to learn 
> than Python 2. But I don't think the learning curve is any steeper.

Set against the “more features in Python 3” is the “more inconsistencies
and cruft in Python 2”.

How to weigh those objectively is beyond me, but my experience is that
the inconsistencies in Python 2 make it more difficult for newcomers
than Python 3.

> If anything, the learning curve is ever-so-slightly less steep.

Yes. The language Python 3 is more consistent with fewer historical edge
cases the beginner needs to know; and the new features don't have to be
learned all at once. Both of which mean that the newcomer has an easier
time in Python 3.

-- 
 \ “Not to perambulate the corridors in the hours of repose in the |
  `\  boots of ascension.” —ski hotel, Austria |
_o__)  |
Ben Finney

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

Re: Guido on python3 for beginners

[Paul Rubin]

Steven D'Aprano  writes:
> I suppose that it is objectively correct that it is harder to learn
> than Python 2. But I don't think the learning curve is any steeper. If
> anything, the learning curve is ever-so-slightly less steep.

I think py3 has more learning curve because it uses iterators in places
where py2 uses lists.  That's a significant new concept and it can be
bug-prone even for programmers who are experienced with it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Random832]

On Thu, Feb 18, 2016, at 01:47, Steven D'Aprano wrote:
> There are more features in Python 3, so in that trivial sense of "more to 
> learn", I suppose that it is objectively correct that it is harder to
> learn 
> than Python 2. But I don't think the learning curve is any steeper. If 
> anything, the learning curve is ever-so-slightly less steep.

I wonder if (with one of the major differences being the unicode thing)
there is a differences between the learning curve for people whose
primary prior experience is with languages that use byte strings for
text (such as perl, [as typically used] C, shell/awk/etc, PHP, python 2)
vs languages that use some form of unicode string (UTF-8 byte strings on
a platform whose default encoding is also UTF-8 don't count) for text
(such as java, C#, javascript).

I feel like the unicode string stuff (issues like encodings etc) is
something that you only have to learn _once_, and then if you really
understand it then for a new language you can just look up how to do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Chris Angelico]

On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
 wrote:
> There are more features in Python 3, so in that trivial sense of "more to
> learn", I suppose that it is objectively correct that it is harder to learn
> than Python 2. But I don't think the learning curve is any steeper. If
> anything, the learning curve is ever-so-slightly less steep.

Let's see... changes in Py3.

1) Division of two integers now yields a float instead of flooring.
For someone fresh to programming, that's a Py3 advantage, although it
can cause surprises elsewhere. But since 1.0==1, it's not going to be
a problem for a new programmer. Advantage: Py3.

2) Strings are Unicode text, and files etc may need to have their
encodings declared. Definitely causes some issues in ASCII-only
situations, where a lot of other languages (notably including PHP, for
the people building web sites) let you be sloppy. Advantage: Py3 if
you speak any language other than English; otherwise Py2 in the very
short term, neither in the medium term, and most definitely Py3 in the
long term (no more "funny characters break my program" errors long
after deployment).

3) Laziness. When you explain to someone what the range() function
does, Py2 makes a list, but Py3 makes... a range. It doesn't really
answer the question at all. When you ask Py2 for a dictionary's
keys/values, you get a list; Py3 gives you a thing that mostly acts
like a list, only it isn't. If you map a function over a list, you get
back a lazy thing that will eventually call that function. Py2 often
has less levels of indirection, ergo less things to try to explain.
Advantage: Py2; the benefits (lower memory usage, etc) aren't
significant to new users.

4) Exception chaining. You get more information when errors cascade.
Advantage: Py3, easily and without any question.

5) print statement/function. Py3 forces you to put parentheses on it,
which is no different from C's printf() or Pike's write() or any
number of other languages where console I/O needs no language support.
Maybe a tiny TINY advantage to Py2 in the short term, but as soon as
you introduce the less basic features, keyword arguments are way
better than the magic syntax the statement needs. (Also, trying to
explain the interaction between the print statement's "soft space" and
other console I/O is not easy.) By the time you've really learned the
language, the advantage belongs to Py3.

6) The fact that the name "python" may not invoke the interpreter you
want. Advantage: Py2, if any; there'll be times when they're on par,
but Py3 never comes out ahead.

7) Whether or not the interpreter comes pre-installed on your system.
As of a few years ago, that was a clear advantage to Py2 (most systems
would ship with both, or neither, or Py2 only), but that's shifting.
It's only a small difference, though; on Windows, you generally get
nothing, and on any system with a decent package manager, you should
be able to request either version with ease.

It's actually a pretty tough call. Most of the Py3 advantages aren't
for the absolute beginner; it's not easier to write "Hello, world" in
Py3, and aside from the change to integer division, most of the
changes won't benefit small-to-medium scripts either. The biggest
advantage (Unicode by default) really only shows itself by sparing you
hassles later on - it's not going to make your life easier in the
short term, ergo it's not going to make the language easier to learn.
Py3 isn't so much easier as _better_. There are specific situations
where it's massively better, but for the most part, they're about on
par.

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

Re: Python keyword args can be any string

[Mark Lawrence]

On 18/02/2016 05:42, Steven D'Aprano wrote:

Today I learned that **kwargs style keyword arguments can be any string:

py> def test(**kw):
... print(kw)
...
py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
py> test(**kwargs)
{'': 23, '123': 17, '---': 999, 'abc-def': 42}

Bug or feature?



I'm not sure, but what on earth got you to this in the first place?

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

Mark Lawrence

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