Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Chris Angelico wrote:

Question: How do you get a reference to a Ruby function? Or are they
not first-class objects?


They're not first-class. So, you can't.

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

Re: A question related to the PYTHONPATH

[oyono]

Le mardi 27 mars 2018 07:42:57 UTC+2, dieter a écrit :
> oyono  writes:
> > ...
> > I was thinking, maybe it could have been done this way to enforce not 
> > running module files that are supposed to be bundled into packages as 
> > "independant" python scripts...Therefore, running "python script.py" should 
> > be reserved to effectively independant python scripts that do not import 
> > from a user-created package or module.
> 
> When you run "python 

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Ned Batchelder wrote:
"Ranting Rick" isn't trying 
to enlighten, educate, or learn. He's trying to rile people up, and he 
is good at it.


I don't think he's even trying, it just come naturally
to him. Rick rants the way wind blows and water wets.

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

To super or not to super (Re: Accessing parent objects)

[Gregory Ewing]

The idea that super() is *always* the right way to call
inherited methods in a multiple inheritance environment
seems to have been raised by some people to the level
of religous dogma.

I don't buy it. In order for it to work, the following
two conditions must hold:

1) All the methods involved have "additive" behaviour,
i.e. the correct thing to do is always to call *all*
versions of the method with the same arguments.

2) It doesn't matter what order they're called in.

The trouble is, those conditions don't always hold.
Often when overriding a method, you want to do something
*instead* of what the base method does. Or you want to
do something additional, but the base method must be
called *first*.

In those situations, there's no way to guarantee that
the right thing will happen by using super().

On the other hand, explicit inherited method calls give
you precise control over what happens and what order it
happens in, with no chance of it being messed up by
someone ineriting from you.

Yes, diamonds can be a problem. You can mitigate that
by (1) avoiding diamonds; (2) if you can't avoid
diamonds, avoid putting methods in the apex class that
get called as inherited methods; (3) if you can't avoid
either of those, as far as I can tell the situation is
intractable and you need to rethink your design.

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

Re: Invoke an independent, non-blocking process from Python 3.6?

[Chris Angelico]

On Tue, Mar 27, 2018 at 2:32 PM,   wrote:
> On Monday, March 26, 2018 at 5:45:40 PM UTC-7, Chris Angelico wrote:
>> On Tue, Mar 27, 2018 at 11:18 AM,   wrote:
>> > I have used multiprocessing before when I wrote some parallelized code.  
>> > That program required significant communication between processes, and 
>> > it's overkill for my purpose here.  I don't need communication between the 
>> > spawning (live data) program and the spawned program.  In fact, to the 
>> > extent that the live data program has to pay attention to anything besides 
>> > the data stream, I think it could be bad.
>> >
>> > I have been investigating the subprocess module.  I'm looking for 
>> > something which behaves like subprocess.run("python3 my_program.py"), but 
>> > which does not "Wait for command to complete, then return a 
>> > CompletedProcess instance."
>> >
>> As far as I know, subprocess.run() will always wait for the process to
>> complete. But you can use the Popen constructor.
>
> Thank you Chris, subprocess.Popen worked nicely for me.  I had to set 
> shell=True to make it work, but it did work.  All parts of my program now 
> operate independently and crash-free!
>

Hmm. Can you post your code? Often shell=True isn't needed.

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

Re: A question related to the PYTHONPATH

[dieter]

oyono  writes:
> ...
> I was thinking, maybe it could have been done this way to enforce not running 
> module files that are supposed to be bundled into packages as "independant" 
> python scripts...Therefore, running "python script.py" should be reserved to 
> effectively independant python scripts that do not import from a user-created 
> package or module.

When you run "python 

Re: Entering a very large number

[Richard Damon]

On 3/26/18 8:46 AM, bartc wrote:

On 26/03/2018 13:30, Richard Damon wrote:

On 3/26/18 6:31 AM, bartc wrote:


The purpose was to establish how such int("...") conversions compare 
in overheads with actual arithmetic with the resulting numbers.


Of course if this was done in C with a version that had builtin 
bignum ints or an aggresive enough optimizer (or a Python that did a 
similar level of optimizations) this function would just test the 
speed of starting the program, as it actually does nothing and can be 
optimized away.


Which is a nuisance. /You/ are trying to measure how long it takes to 
perform a task, the compiler is demonstrating how long it takes to 
/not/ perform it! So it can be very unhelpful.


Hence my testing with CPython 3.6, rather than on something like PyPy 
which can give results that are meaningless. Because, for example, 
real code doesn't repeatedly execute the same pointless fragment 
millions of times. But a real context is too complicated to set up.
The bigger issue is that these sort of micro-measurements aren't 
actually that good at measuring real quantitative performance costs. 
They can often give qualitative indications, but the way modern 
computers work, processing environment is extremely important in 
performance, so these sorts of isolated measure can often be misleading. 
The problem is that if you measure operation a, and then measure 
operation b, if you think that doing a then b in the loop that you will 
get a time of a+b, you will quite often be significantly wrong, as cache 
performance can drastically affect things. Thus you really need to do 
performance testing as part of a practical sized exercise, not a micro 
one, in order to get a real measurement.


 Yes, something like this can beused to measure the base time to do
something, but the real question should be is that time significant 
compared to the other things that the program is doing, Making a 200x 
improvement on code that takes 1% of the execution time saves you 
0.995%, not normally worth it unless your program is currently 
running at 100.004% of the allowed (or acceptable) timing, if 
acceptable timing can even be defined that precisely.


I'm usually concerned with optimisation in a more general sense than a 
specific program.


Such a with a library function (where you don't know how it's going to 
be used); or with a particular byte-code in an interpreter (you don't 
know how often it will be encountered); or a generated code sequence 
in a compiler.


But even 200x improvement on something that takes 1% of the time can 
be worthwhile if it is just one of dozens of such improvements. 
Sometimes these small, incremental changes in performance can add up.


And even if it was just 1%, the aggregate savings across one million 
users of the program can be substantial, even if the individuals won't 
appreciate it. 1% extra battery life might be a handy five minutes for 
example.


Yes, but if you find where you are really spending your time, a similar 
effort may give significantly larger improvements.


--
Richard Damon

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

Re: Invoke an independent, non-blocking process from Python 3.6?

[jladasky]

On Monday, March 26, 2018 at 5:45:40 PM UTC-7, Chris Angelico wrote:
> On Tue, Mar 27, 2018 at 11:18 AM,   wrote:
> > I have used multiprocessing before when I wrote some parallelized code.  
> > That program required significant communication between processes, and it's 
> > overkill for my purpose here.  I don't need communication between the 
> > spawning (live data) program and the spawned program.  In fact, to the 
> > extent that the live data program has to pay attention to anything besides 
> > the data stream, I think it could be bad.
> >
> > I have been investigating the subprocess module.  I'm looking for something 
> > which behaves like subprocess.run("python3 my_program.py"), but which does 
> > not "Wait for command to complete, then return a CompletedProcess instance."
> >
> As far as I know, subprocess.run() will always wait for the process to
> complete. But you can use the Popen constructor.

Thank you Chris, subprocess.Popen worked nicely for me.  I had to set 
shell=True to make it work, but it did work.  All parts of my program now 
operate independently and crash-free!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: issues when buidling python3.* on centos 7

[Michael Torrie]

On 03/25/2018 10:15 AM, joseph pareti wrote:
> The following may give a clue because of inconsistent python versions:
> 
> [joepareti54@xxx ~]$ python -V
> Python 3.5.2 :: Anaconda 4.3.0 (64-bit)

What does 'which python' return?  As Joseph said, hopefully you didn't
overwrite /usr/bin/python with Python 3.5.  If you did, you're hosed.
You'll probably have to reinstall.  Python 2.7 is required by just about
everything on CentOS 7.

If you want to use Python 3.4, install it via Software Collections
Library.  https://www.softwarecollections.org/en/

To use SCL, you'll need a working yum, though, so after you reinstall
give it a try.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 6:11:31 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
[...]
> > Hmm. If "syntax parser rules" could prevent poorly
> > formatted code, then there'd be no need for style guides.
>
> It may be telling that my team has minimal style standards
> for C/C++, and none at all for Python... [We don't feel it
> requires any.]

Hmm, which would indicate to me you're part of a small,
tight-nit group of like-minded folks. However, what works
well for small groups begins to fall apart in larger
social environment.

> > > > No self-respecting professional programmer would ever
> > > > write in such a manner.
>
> I should also have said that I think this assumes a certain
> level of expertise with the language.  We all start out as
> novices with every new language, and may spend a very long
> time there, depending on how much we use it...

Hmm, very true. If only Steven had been more experienced with
Ruby, then he would have known to avoid that pitfall. O:-)

> > Perl is a special case (and thus not a good retort)
> > because the language itself was purposely intended to be
> > cryptic.
>
> I think Larry would disagree with that assessment...

And that's an opinion he gets to have ;-)

[...]

> > IOWs: It's not a bug, dude, it's a feature.
>
> I dunno, this smells a lot like BS.
>
> Ruby touts itself as being a simple language with elegant
> syntax. This thread is my only exposure to it to date, but
> what I've seen here is, frankly, the exact opposite of
> that.

And do you normally judge the worthiness of an entire
language based on one poorly styled non-idiomatic example
created by somone who is (admittingly) not intimately
familiar with the language?

> You should not need a map to distinguish function
> calls from variables,

I agree that the Python mandated empty parens is a nicely
intuitive indication of a func-call, and that's why i use
the empty parens in all my Ruby code (even though Ruby does
not force me to). Hmm, I'm not sure why Matz chose to make
the syntax optional. But whatever his reason may have benn,
i just hold down shift, and strike two keys, and -- whamo --
my coding style is consistent.

> or operands from function arguments,

Agreed. The syntax "foo(x, y, z)" nicely encapsulates
the arguments whereas "foo x, y, z" does not.

> let alone have the latter depend on the position of the
> operator token relative to any whitespace between it and
> the two tokens on either side of it.  That's hard to read,
> complicated, inelegant, and just poor syntax. [My opinion,
> obviously.] That's not enough exposure to decide that the
> language isn't simple and elegant overall, but it certainly
> does induce a strong negative prejudice.

You shouldn't dismiss Ruby over this one little issue. Need
i remind you that Python has its fair share of warts? In
fact, here is one involving Python's implicit self which
occasionally bites even the seasoned pythonista:

>>> class Foo(object):
... def bar(self, arg1, arg2, arg3):
... pass
>>> foo = Foo()
>>> foo.bar(1,2)
Traceback (most recent call last):
  File "", line 1, in 
foo.bar(1,2)
TypeError: bar() takes exactly 4 arguments (3 given)

(A reinactment of programmer mental state follows)

"Huh?" o_O

"I gave _three_ arguments, you say?" o.O

"Wuh-wuh-what?" O_O

"_THREE_?" #_O

"What the hell are your talking about Python?" ಠ_ಠ

"Are you blind?" (╯°□°）╯︵ ┻━┻

"Cause I'm _looking_ at the freaking code..."  ＼(°ロ＼)

"And i'm _looking_ at the freaking exception..." (／ロ°)／

"but what you're telling me just don't add up!" \(`Д´)

"YOU LIAR!!!"  ┻━┻︵ヽ(`Д´)ﾉ︵ ┻━┻

"Okay. Alright. Listen. I _swears_..."  щ(ﾟДﾟщ)

"I only gave you *TWO* arguments -- just two!" (屮ﾟДﾟ)屮

"WOE IS ME!" （´Д｀）

"I'm so terribly vexed!" (>_<)

"What have i done to deserve this?" （ ´,_ゝ`)

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

Re: Invoke an independent, non-blocking process from Python 3.6?

[Chris Angelico]

On Tue, Mar 27, 2018 at 11:18 AM,   wrote:
> I have used multiprocessing before when I wrote some parallelized code.  That 
> program required significant communication between processes, and it's 
> overkill for my purpose here.  I don't need communication between the 
> spawning (live data) program and the spawned program.  In fact, to the extent 
> that the live data program has to pay attention to anything besides the data 
> stream, I think it could be bad.
>
> I have been investigating the subprocess module.  I'm looking for something 
> which behaves like subprocess.run("python3 my_program.py"), but which does 
> not "Wait for command to complete, then return a CompletedProcess instance."
>

Yeah, that sounds like the right solution. So you want a "fire and
forget" system. First, a caveat: you MAY have problems if the parent
process ends before the child does. (They can be solved but I don't
know whether naive use of subprocess will do that.)

As far as I know, subprocess.run() will always wait for the process to
complete. But you can use the Popen constructor.

>>> subprocess.run(["/bin/bash", "-c", "sleep 2; echo bash"]); 
>>> print("Python")bash
CompletedProcess(args=['/bin/bash', '-c', 'sleep 2; echo bash'], returncode=0)
Python
>>> subprocess.Popen(["/bin/bash", "-c", "sleep 2; echo bash"]); print("Python")

Python
>>> bash

You get back a subprocess.Popen object immediately. What I did here
left its standard streams connected to my parent process's streams, so
if the child process tries to print to stdout, it appears in the same
console. If you set those to be pipes or anything, you have to worry
about them filling up; otherwise, this should work for you.

BTW, if you need to run something using the same Python interpreter
that started you, "sys.executable" may help.

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

RE: issues when buidling python3.* on centos 7

[Joseph L. Casale]

-Original Message-
From: Python-list  On Behalf Of joseph
pareti
Sent: Sunday, March 25, 2018 10:15 AM
To: python-list@python.org
Subject: issues when buidling python3.* on centos 7

> The following may give a clue because of inconsistent python versions:
> 
> [joepareti54@xxx ~]$ python -V
> Python 3.5.2 :: Anaconda 4.3.0 (64-bit)

You replaced your system Python with 3.5.2? Redhat (CentOS) wont
work without its shipped Python 2.7.5 as the only `python`. Things like
SCL's and IUS use alternative and safe ways to bring in additional versions
without breaking the system version. I have never used your new version
but it looks like it was not built (or installed) correctly for the platform.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 10:10 AM, Python  wrote:
> Ruby touts itself as being a simple language with elegant syntax.
> This thread is my only exposure to it to date, but what I've seen here
> is, frankly, the exact opposite of that.  You should not need a map to
> distinguish function calls from variables, or operands from function
> arguments, let alone have the latter depend on the position of the
> operator token relative to any whitespace between it and the two
> tokens on either side of it.  That's hard to read, complicated,
> inelegant, and just poor syntax. [My opinion, obviously.] That's not
> enough exposure to decide that the language isn't simple and elegant
> overall, but it certainly does induce a strong negative prejudice.

My understanding of Ruby's design model is that it prefers "intuitive"
to "easy to explain". That means there's a lot of magic to make things
behave the way you would expect. The trouble is that you then end up
with edge cases; the benefit is that you get an easy REPL. Let me
compare three REPLs for you (I'm not a Ruby expert so I won't use it
here):

=== JavaScript ===
rosuav@sikorsky:~$ node
> function f() {
... let x = 1
... let y = 2
... return x + y
... }
undefined
> f()
3
>

=== Pike ===
rosuav@sikorsky:~$ pike
Pike v8.1 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Ok.
> int f() {
>> int x = 1;
>> int y = 2;
>> return x + y;
>> }
> f();
(1) Result: 3
>

=== Python ===
rosuav@sikorsky:~$ python3
Python 3.8.0a0 (heads/literal_eval-exception:ddcb2eb331, Feb 21 2018, 04:32:23)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... x = 1
... y = 2
... return x + y
...
>>> f()
3
>>>

===

Python and Pike have fairly simple rules. In Python, a statement ends
at the newline, and a function's body must be indented. That means I
have to hit Tab at the beginning of each line until I'm done. (AIUI
other Python front ends do things differently, but I don't have
ipython handy to test.) Pike defines things by semicolons, so I have
to toss a semicolon after each statement, even in the REPL (it's
annoying to have to write "f();" not just "f()"), but the UI doesn't
need indentation, and it just modifies the prompt to indicate nesting
level (which is controlled by braces).

JavaScript, on the other hand, has far more complex rules. The benefit
is that, like with Python, semicolons aren't required, and like with
Pike, indentation can be skipped when you're typing at the REPL. The
downside is that... well, let's try breaking one of those lines.
First, in Pike:

rosuav@sikorsky:~$ pike
Pike v8.1 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Ok.
> int f() {
>> int x = 1;
>> int y = 2;
>> return
>> x + y;
>> }
>
> f()
>> ;
(1) Result: 3
>

Exactly the same. The semicolons define it. A line break after "f()"
requires the semi before the code runs. The line break after "return"
doesn't change anything.

rosuav@sikorsky:~$ node
> function f() {
... let x = 1;
... let y = 2;
... return
... x + y;
... }
undefined
> f();
undefined
>

Strange... even though I have all the semicolons, it's still borked.
Because JS has complicated rules about implicit semicolons. Yes, this
is an edge case (the "return" statement takes an optional expression,
so it's legal on its own - it'd be different if I broke the line
before or after an equals sign, for instance, as the two lines
wouldn't be legal on their own), but you get more edge cases when you
create more magic.

Ruby appears to have created a corner case here. It's an extremely
weird one, and it's a consequence of the fact that (a) you can call a
function just by naming it OR by naming it and giving a parameter, and
(b) the plus operator has both unary and binary forms. But you can't
change the plus operator without breaking a LOT of people's
expectations (and even if you decide to disallow unary plus, the exact
same problem will happen with unary minus, and you can't get rid of
that one), and the ability for functions to accept optional arguments
is an excellent feature. So the only way to solve this is to remove
the ability for functions to be called without parentheses.

Question: How do you get a reference to a Ruby function? Or are they
not first-class objects?

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Ned Batchelder]

On 3/26/18 7:10 PM, Python wrote:

Humans are already good enough at making mistakes that they
require no additional encouragement, such as what is
provided by allowing such syntactical horrors.

Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down by those who
struggled before us. Sure, the behavior that Steven
uncovered is odd, but it could be that Maz harbors a strong
disliking for undisciplined pupils

[...]

IOWs: It's not a bug, dude, it's a feature.

I dunno, this smells a lot like BS.


It's a losing game to engage Rick in debate: "Ranting Rick" isn't trying 
to enlighten, educate, or learn. He's trying to rile people up, and he 
is good at it.


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

Invoke an independent, non-blocking process from Python 3.6?

[jladasky]

Hi folks,

I've run into an odd situation.  I have a custom USB peripheral device which 
generates real-time data.  I monitor this device using a PyQt5 app that I 
wrote.  Periodically I want to capture some of this data in files.  Because of 
a transient OS bug which apparently involves a corner case in the Linux serial 
port driver (!), I cannot guarantee that I can transmit commands to the device 
to shut off data transmission while I'm saving a file.

When my setup gets handicapped with just one-way communication, the PyQt5 file 
selector dialog box pauses for an unusually long time.  My data gets saved to 
disk, but then my application segfaults.  I have to restart the whole device.  
In time-critical data acquisition, this won't be good.

My hypothesis is that the PyQt message queue is getting choked with data during 
the disk write operation, and/or when the QFileDialog box pops up.  I can't 
prove this, but I am contemplating a work-around.  I plan to separate my data 
analysis and annotation windows completely from the live data-acquisition 
application.

I just modified my program so that the data streams to a file in /tmp from the 
acquisition program when I click a Record button.  I can click a Stop button, 
and the /tmp file closes without crashing the live data application.  I can 
repeat this as often as I want.  So far, so good.

My CPU has a dozen cores.  I think that all I need to do now is to start a 
second Python interpreter which runs an analysis-only application.  Then when 
the QFileDialog from the analysis app is on the screen, there's no chance that 
it would disrupt the message queue in the live-acquisition app.

I have used multiprocessing before when I wrote some parallelized code.  That 
program required significant communication between processes, and it's overkill 
for my purpose here.  I don't need communication between the spawning (live 
data) program and the spawned program.  In fact, to the extent that the live 
data program has to pay attention to anything besides the data stream, I think 
it could be bad.

I have been investigating the subprocess module.  I'm looking for something 
which behaves like subprocess.run("python3 my_program.py"), but which does not 
"Wait for command to complete, then return a CompletedProcess instance."

Any suggestions are appreciated.  Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String Formatting with new .format()

[W Yg]

在 2018年3月26日星期一 UTC+8下午11:37:46，Ganesh Pal写道：
> Hi Team,
> 
> Just a quick suggestion, on string formatting with .format() which of the
> below is better , given both give the same result .
> 
> >>> attempts = 1
> >>> msg2 = "Hello"
> >>> print "Retry attempt:{0} for error:{1}".format(attempts,msg2)
> Retry attempt:1 for error:Hello
> 
> OR
> 
> >>> attempts = 1
> >>> msg2 = "Hello"
> >>> print "Retry attempt:{0} for error:{0}".format(attempts,msg2)
> Retry attempt:1 for error:1
> >>>
> 
> 
> PS : This is the silly question but I wanted to know if it really makes any
> difference
> 
> I am on Python 2.7 and Linux
> 
> Regards,
> Ganesh

The method  format of str can have extra arguments. I think it is more elegance 
than used like this way 
>>> print "Retry attempt:%s for error:%s". % (attempts,msg2)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question related to the PYTHONPATH

[oyono]

Le lundi 26 mars 2018 08:11:02 UTC+2, dieter a écrit :
> adrien oyono  writes:
> > I have recently read the documentation about how imports work on python,
> > and I was wondering why, when you execute a python file, the current
> > directory is not added by default to the PYTHONPATH ?
> 
> Maybe, to avoid surprises?
> 
> You can invoke a script from different positions in your file system.
> If PYTHONPATH would automatically get ".", the script's behaviour
> could depend on the position from where it is called.
> 
> Prepending "." to "PYTHONPATH" could have dramatic effects:
> assume your script uses module "xxx" and your current working
> directory accidentally has a "xxx.py"; then this "xxx.py" would
> be used and it may behave much differently from another one.
> 
> The problem is not so severe when "." is appended to "PYTHONPATH".
> Nevertheless, it likely is not a good idea to have script behaviour
> depending by default on the execution location.

Thank you Dieter.
I was thinking, maybe it could have been done this way to enforce not running 
module files that are supposed to be bundled into packages as "independant" 
python scripts...Therefore, running "python script.py" should be reserved to 
effectively independant python scripts that do not import from a user-created 
package or module.
I think I need to learn a little bit more about the python cli.
Many thanks again
-- 
https://mail.python.org/mailman/listinfo/python-list

Fw: Fwd: Welcome to the "Python-list" mailing list

[nadir musallam]

Dear All,


I have tried installing Python3.6.4 on my computer as I am eager to begin a new 
career in data analytics. However I am running in to some problems when 
attempting to set up the software. I have downloaded Dev C++ software as per 
your recommendation earlier but still getting the same error when trying to 
launch the program. Your assistance would be very much appreciated. I hope this 
time I followed the proper instructions for the emailing list as it is not my 
intention to offend anyone.

Below is the updated log file for your reference:


[1D14:0FEC][2018-03-26T09:09:13]i001: Burn v3.10.3.3007, Windows v10.0 (Build 
16299: Service Pack 0), path: 
C:\Users\DELL\AppData\Local\Temp\{38A48442-951B-485A-BF38-8B6263D4F87D}\.cr\python-3.6.4-amd64-webinstall.exe
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ShortVersion' to value '3.6'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '36'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 'WinVer' to 
value '3.6'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'WinVerNoDot' to value '36'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 'TargetDir' 
to value ''
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFiles64Folder]Python[WinVerNoDot]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetPlatform' to value 'x64'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstallPath'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_core' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_exe' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_dev' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_lib' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_test' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_doc' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_tools' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_pip' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'Include_launcherState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_debug' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'DetectedLauncher' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'DetectedOldLauncher' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'AssociateFiles' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 'Shortcuts' 
to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'PrependPath' to value '0'
[1D14:0FE

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
> On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> > On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> [...]
> > > Ruby followed the rules.
> > > But you didn't.
> >
> > Nonsense... Your language's syntax parser is what defines
> > the rules. All of the expressions Stephen wrote did not
> > yeild a syntax error, therefore he "followed the rules."
> 
> Hmm. If "syntax parser rules" could prevent poorly formatted
> code, then there'd be no need for style guides.

It may be telling that my team has minimal style standards for C/C++,
and none at all for Python... [We don't feel it requires any.]

> > > No self-respecting professional programmer would ever
> > > write in such a manner.

I should also have said that I think this assumes a certain level of
expertise with the language.  We all start out as novices with every
new language, and may spend a very long time there, depending on how
much we use it...  So, basically, I'm saying that's false. :)

> > I think your expectation here is much too high.  I've seen
> > A LOT of Perl written by, for example, professional
> > testers, of this ilk, and I've seen it cause bugs when a)
> > they got the syntax very slightly wrong, or b) they got the
> > syntax right but someone else to whom the intention wasn't
> > clear "fixed" it.
> 
> Perl is a special case (and thus not a good retort) because
> the language itself was purposely intended to be cryptic.

I think Larry would disagree with that assessment...

> Thus, what Perl programmers consider to be "normal and
> perfectly acceptable code" would cause the rest of us to run
> away in horror.

Regardless of what Larry says, I agree with that assessment.  Perl has
been relegated to "only use when there is no option" in my regieme,
which basically means only when it is absolutely necessary to maintain
some legacy garbage that's already Perl.

> > Humans are already good enough at making mistakes that they
> > require no additional encouragement, such as what is
> > provided by allowing such syntactical horrors.
> 
> Agreed. And that's why we must respect and follow the code
> styling wisdom which has been passed down by those who
> struggled before us. Sure, the behavior that Steven
> uncovered is odd, but it could be that Maz harbors a strong
> disliking for undisciplined pupils
[...]
> IOWs: It's not a bug, dude, it's a feature.

I dunno, this smells a lot like BS.

Ruby touts itself as being a simple language with elegant syntax.
This thread is my only exposure to it to date, but what I've seen here
is, frankly, the exact opposite of that.  You should not need a map to
distinguish function calls from variables, or operands from function
arguments, let alone have the latter depend on the position of the
operator token relative to any whitespace between it and the two
tokens on either side of it.  That's hard to read, complicated,
inelegant, and just poor syntax. [My opinion, obviously.] That's not
enough exposure to decide that the language isn't simple and elegant
overall, but it certainly does induce a strong negative prejudice.

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

Fwd: Fwd: ftplib sending data out of order

[Charles Wilt]

Just to close out this thread in case anybody finds it...

We're reasonably sure the issue was cause by version 14.6 MP1 of Symantec
Vontu; which is a Data Loss Prevention (DLP) product that "inspects"
packets before they leave the PC.

I believe the issue was reported to Symantec.

In the meantime, we worked around the issue by extending the base ftplib.FTP
 class and adding a new function:

#stortext combines block read from STORBINARY with ASCII transfer mode
from STORLINEdef stortext(self, cmd, fp, blocksize=8192,
callback=None, rest=None):
self.voidcmd('TYPE A')
conn = self.transfercmd(cmd, rest)
while 1:
buf = fp.read(blocksize)
if not buf: break
conn.sendall(buf)
if callback: callback(buf)
conn.close()
return self.voidresp()

We stopped having issues with scrambled code. As a bonus, the transfer run
considerably faster than they did with storline.

So we've continued to use our new function.


On Mon, Jul 10, 2017 at 7:23 AM, Charles Wilt 
wrote:

> I downloaded the 3.6.1 source and added some debug logging to
> sock_sendall() and sock_send_impl() in socketmodule.c.
>
> As I understand it, sock_send_impl() is where the data is passed to the
> OS.
>
> I can see that sock_send_impl() is getting the data in the correct order.
>
>
>
>
> On Wed, Jul 5, 2017 at 2:03 PM, Dieter Maurer  wrote:
>
>> Charles Wilt wrote at 2017-7-5 11:08 -0600:
>> >On Mon, Jul 3, 2017 at 4:24 PM, Dieter Maurer 
>> wrote:
>> >
>> >>
>> >> It is not the "readline" that changes depending on the callback.
>> >> Keep in mind that "conn.sendall" can return before the bytes are
>> actually
>> >> sent.
>> >>
>> >
>> >?Not according to this answer
>> >https://stackoverflow.com/questions/34252273/what-is-the-di
>> fference-between-socket-send-and-socket-sendall
>>
>> "sendall" internally calls "send" until all the bytes passed as argument
>> are accepted by "send". Below "send", the things are packeted, transmitted
>> and reassembled.
>>
>> If send returns, this does *not* mean that the data has been successfully
>> transfered. It only means that a lower level has taken over responsibilty
>> for the transfer.
>>
>> As a consequence, "sendall" may return before the data has been
>> successfully transfered; it only means that the complete data was
>> accepted by the lower (network) level.
>>
>>
>> >And if sendall can return before the data is sentwouldn't that make
>> it
>> >the wrong choice for an FTP client?
>>
>> Why?
>>
>> The data is transfered to the lower level and this has taken
>> over responsibility for the transfer. "ftplib" is using a TCP socket.
>> TCP promises to ensure a reliable transfer (by using retransmissions, if
>> necessary and possible). Under normal conditions, the data will be
>> transfered;
>> thus, why wait until the transfer is complete.
>>
>>
>>
>> --
>> Dieter
>>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

please test the new PyPI (now in beta)

[Sumana Harihareswara]

The new Python Package Index at https://pypi.org is now in beta.

This means the site is robust, but we anticipate needing more user
testing and changes before it is "production-ready" and can fully
replace https://pypi.python.org . We hope to complete the transition
before the end of April 2018.

We're still working to ensure the new codebase and infrastructure are
reliable. So please don't rely on it (yet) unless you can handle the
occasional minor outage.

But we want you to try the new PyPI, test it, and tell us if you have
any problems. During the beta, we'll have IRC and Twitter livechats to
hear from you:

* Tuesday, March 27th, 16:00-17:00 UTC
* Friday, March 30th, 14:00-15:00 UTC
* Tuesday, April 3rd, 15:00-16:00 UTC
* Friday, April 5th, 0:00-1:00 UTC

More at
https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html
.

For future PyPI news, please subscribe to the low-traffic PyPI
announcement email list:
https://mail.python.org/mm3/archives/list/pypi-annou...@python.org/

Thank you.
-- 
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] multicore/cpu history

[Gene Heskett]

On Monday 26 March 2018 12:12:46 Dennis Lee Bieber wrote:

> On Mon, 26 Mar 2018 11:30:54 -0400, Gene Heskett
> 
>
> declaimed the following:
> >On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote:
>
>   
>
> >>As I recall, the bootloader on the Raspberry Pi runs on the
> >> graphics processor, and it sets up the memory image for Linux
> >> before passing control to the ARM processor.
> >
> >Does that come with docs on how to change kernels in case the one you
> > are running has to be rebooted 2-10 times to get the keyboard/mouse
> > ducks all in a row so it doesn't randomly throw away events?
>
>   If Broadcom hasn't changed things, the bootloader is a black-box blob
> provided by Broadcom to the R-Pi foundation. The Linux kernel likely
> falls under regular Linux image management (the bootloader doesn't
> contain the Linux image, just runs on the graphics processor to load
> Linux). I don't think R-Pi uses U-Boot (whereas the BeagleBone Black
> is shoving everything into U-Boot -- making most of the BBB text books
> out-of-date as the kernel no longer loads device tree overlays,
> they've been pre-loaded by U-Boot)

Which to me, isn't a lot of help. But, thats broadcom...

Too bad I can't put a bounty on them. It seems to me that any outfit with 
more lawyers than engineers ought to fall over from top heavy and foot 
damage eventually, but they seem to be the exception to that rule.

OTOH, its even harder to get any usable info out of Pine to facilitate 
using an rtai kernel on a product of theirs called a rock64.  Which can 
build that kernel in under an hour. And it does use u-boot, or claims 
to.  Here we have another credit card sized boy wonder computer thats 
probably 10x or more faster than a top of the line pi, with a usb3 port, 
and the info as to how to make it work seems locked in a safe behind 
non-disses they can't even admit to.

Hell of a way to run a train.  Thanks Dennis.

> --
>   Wulfraed Dennis Lee Bieber AF6VN
>   wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/



-- 
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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
[...]
> > Ruby followed the rules.
> > But you didn't.
>
> Nonsense... Your language's syntax parser is what defines
> the rules. All of the expressions Stephen wrote did not
> yeild a syntax error, therefore he "followed the rules."

Hmm. If "syntax parser rules" could prevent poorly formatted
code, then there'd be no need for style guides.

> > No self-respecting professional programmer would ever
> > write in such a manner.
>
> I think your expectation here is much too high.  I've seen
> A LOT of Perl written by, for example, professional
> testers, of this ilk, and I've seen it cause bugs when a)
> they got the syntax very slightly wrong, or b) they got the
> syntax right but someone else to whom the intention wasn't
> clear "fixed" it.

Perl is a special case (and thus not a good retort) because
the language itself was purposely intended to be cryptic.
Thus, what Perl programmers consider to be "normal and
perfectly acceptable code" would cause the rest of us to run
away in horror.

"Debug that mess?" o_O

"NO WAY!"

> Humans are already good enough at making mistakes that they
> require no additional encouragement, such as what is
> provided by allowing such syntactical horrors.

Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down by those who
struggled before us. Sure, the behavior that Steven
uncovered is odd, but it could be that Maz harbors a strong
disliking for undisciplined pupils, and thus, he designed
and placed this little trap in the hopes the pain it induced
might encourage the petulant little meat-heads to follow
some sensible styling rules.

IOWs: It's not a bug, dude, it's a feature.

PS: ("meat-head": it's what's for dinner)

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

Re: Entering a very large number

[Christian Gollwitzer]

Am 26.03.18 um 12:31 schrieb bartc:

On 26/03/2018 10:34, Steven D'Aprano wrote:

So what exactly did you do?


I did this:

def fn():
     C = int(
     "28871482380507712126714295971303939919776094592797"
     "22700926516024197432303799152733116328983144639225"
     "94197780311092934965557841894944174093380561511397"
     "4215424169339729054237110027510420801349667317"
     "5515285922696291677532547505856101949404200039"
     "90443211677661994962953925045269871932907037356403"
     "22737012784538991261203092448414947289768854060249"
     "76768122077071687938121709811322297802059565867")

#   C = 2887148238050771212671429... [truncated for this post]

     D=C+C

for i in range(100):
     fn()

The purpose was to establish how such int("...") conversions compare in 
overheads with actual arithmetic with the resulting numbers.


I still claim that it is not necessary to perform the conversion on each 
function call. For instance, the following change speeds it up by a 
factor of 7 on my machine:


===
def fn(C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"5515285922696291677532547505856101949404200039"
"90443211677661994962953925045269871932907037356403"
"22737012784538991261203092448414947289768854060249"
"76768122077071687938121709811322297802059565867")):
#   C = 2887148238050771212671429... [truncated for this post]

D=C+C
return D


for i in range(100):
fn()

#print(fn())
===

Out of pure laziness, I haven't compared it to the version with the long 
string. Maybe tha gurus here find yet another elegant way to assign the 
constant only once; my trial with "fn.C = foobar" was not successful.


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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> > Because of this "fix", the printed strings no longer match
> > the code being executed, but the strange, inconsistent
> > behaviour still occurs.
> 
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby, no, it's all on _you_.

This is utter nonsense.  Ruby's parser allowed the
unintuitive/inconsistent behavior, so it has everything to do with
Ruby. 

The fact that the language allows you to write such expressions means
that SOMEONE WILL.  Your own messages seem to promote Ruby's
paren-less function calls as a good thing (which I vehemently disagree
with, but I can accept that's a matter of preference).  However, a
language that allows (a + b) to evaluate to a different value from
(a +b) (at the same execution point) is syntactically abysmal.

> Ruby followed the rules.
> But you didn't.

Nonsense... Your language's syntax parser is what defines the rules.
All of the expressions Stephen wrote did not yeild a syntax error,
therefore he "followed the rules."  

> No self-respecting professional programmer would ever write
> in such a manner. 

I think your expectation here is much too high.  I've seen A LOT of
Perl written by, for example, professional testers, of this ilk, and
I've seen it cause bugs when a) they got the syntax very slightly
wrong, or b) they got the syntax right but someone else to whom the
intention wasn't clear "fixed" it.

Humans are already good enough at making mistakes that they require no
additional encouragement, such as what is provided by allowing such
syntactical horrors.

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 5:37 AM, Rick Johnson
 wrote:
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> the one who created a non-sensical function with a single
> char name; and _YOU_ are the one who placed a call to that
> function in the middle of an expression, which, on first
> glance, looks to be a common numeric addition or string
> concatenation. There are no syntactical clues that `a` is a
> function. Thus, it is _YOU_ who is to blame for the supposed
> "unexpected output".
>
> Ruby followed the rules.
>
> But you didn't.

Yeah, it's entirely Steven's fault that he was expecting cricket but
Ruby wanted to play Calvinball. But hey, Ruby was totally following
the rules.

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 10:43:32AM +, Steven D'Aprano wrote:
> The kicker is that out of these four legal, parenthesis-free ways of 
> calling function a, *three* of them interpret the expression as:
> 
> call a with no arguments
> then add b using the binary plus operator
> 
> but the last, differing only in whitespace, interprets it as:
> 
> call a with a single argument, unary-plus b

Thanks for the explanation.  That's fucking stupid.  I usually prefer
to refrain from cursing in posts but in this case I think that level
of emphasis is required.  And FWIW, this convinces me that Ruby is not
a language I ever want to use.

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Sun, Mar 25, 2018 at 10:33:49AM -0700, Rick Johnson wrote:
> > [steve@ando ruby]$ ruby ws-example.rb
> > a + b => 7
> > a+b   => 7
> > a+ b  => 7
> > a +b  => 3
> >
> > Here's the source code:
> >
> > # --- cut ---
> > def a(x=4)
> > x+2
> > end
> >
> > b = 1
> > print "a + b => ", (a + b), "\n"
> > print "a+b   => ", (a+b), "\n"
> > print "a+ b  => ", (a+ b), "\n"
> > print "a +b  => ", (a +b), "\n"
> > # --- cut ---
> 
> 
> Short of demonstrating that you have knack for writing
> obfuscated code :-), i don't see the point here. 

I think the point is 7 != 3...

> Here, i took the liberty of un-obfuscating your code [...]

Not to me, you didn't.  While I don't know ruby, I already got from
context that "a" was a function call, including without the parens,
albeit annoying to read.  I've previously seen that in Perl, and never
liked it there either, because you can't immediately tell by looking
at it whether it is a variable or a function call.  While I think that
itself speaks to Stephen's consistency point, I don't think that's too
controvercial.

But what I don't get is how the last print statement prints 3.  There
seems to be some kind of magic happening related to the positioning of
the + relative to the operand(s).  That's neither consistent nor
intuitive.  Or, it's some other thing caused by a detail I overlooked,
but if so your "unobfuscated" version did nothing to clarify what that
detail is, even after scrutinizing it somewhat closely.  In either
case, I can't imagine how Ruby arrives at the answer 3.

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

Re: A question related to the PYTHONPATH

[Ian Kelly]

On Mon, Mar 26, 2018 at 1:24 PM, Dan Stromberg  wrote:
> On Sun, Mar 25, 2018 at 11:10 PM, dieter  wrote:
>> adrien oyono  writes:
>>> I have recently read the documentation about how imports work on python,
>>> and I was wondering why, when you execute a python file, the current
>>> directory is not added by default to the PYTHONPATH ?
>>
>> Maybe, to avoid surprises?
>>
>> You can invoke a script from different positions in your file system.
>> If PYTHONPATH would automatically get ".", the script's behaviour
>> could depend on the position from where it is called.
>
> IINM, this also has security implications.

It's curious then that the -m invocation does add the current
directory, since it's normally used for running standard library
scripts like timeit or venv.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question related to the PYTHONPATH

[Dan Stromberg]

On Sun, Mar 25, 2018 at 11:10 PM, dieter  wrote:
> adrien oyono  writes:
>> I have recently read the documentation about how imports work on python,
>> and I was wondering why, when you execute a python file, the current
>> directory is not added by default to the PYTHONPATH ?
>
> Maybe, to avoid surprises?
>
> You can invoke a script from different positions in your file system.
> If PYTHONPATH would automatically get ".", the script's behaviour
> could depend on the position from where it is called.

IINM, this also has security implications.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
> Rick, you're supposedly familiar with Ruby. And yet, you
> didn't notice that your supposed "fix" didn't touch any
> executable code, all it did was modify the strings being
> printed.

Because the goal was to *UN-OBFUSCATE* the code, not to
provide a solution for the problem _you_ created.

> Because of this "fix", the printed strings no longer match
> the code being executed, but the strange, inconsistent
> behaviour still occurs.

The supposed "inconsistent behavior" here has absolutely
nothing to do with Ruby, no, it's all on _you_. _YOU_ are
the one who created a non-sensical function with a single
char name; and _YOU_ are the one who placed a call to that
function in the middle of an expression, which, on first
glance, looks to be a common numeric addition or string
concatenation. There are no syntactical clues that `a` is a
function. Thus, it is _YOU_ who is to blame for the supposed
"unexpected output".

Ruby followed the rules.

But you didn't.

Like a mad scientist you injected obfuscation into your
source code and then blamed Ruby because your poor naming
conventions and your clumsily formed expressions did not
produce the "purdy little result" you expected.
Congratulations, you have forsaken the most vital principle
of good programming -> Readability Counts!.

"Code is read more often than it is written" (ring a bell?).

No self-respecting professional programmer would ever write
in such a manner. Its the kind of crapola that will get you
fired in 2 seconds. Yet, here you are -- THE GREAT AND
POWERFUL D'APRANO -- thumping your chest over this
horrendous code and acting as if we should be proud of you.

Yip of the day: No one is proud of you.

> Here's the code again:

No thanks. I've seen more than i care to see of your little
"examples".

> Of course we can solve the problem by always using
> parentheses when making function calls.

I'm sorry, but _we_ are not required to solve the problems
_you_ create. _You_ made that mess, and now _you_ can clean it
up.

> But that misses the point that Ruby allows this
> inconsistency in the first place.

Hmm, i see. And if the operator of an automobile purposesly
drives off a cliff, who do you blame: driver or
manufacturer?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pip Version Confusion

[Rob Gaddi]

On 03/24/2018 08:40 AM, Tim Johnson wrote:

I'm on Ubuntu 16.04.

I'm getting the following message from pip:

You are using pip version 8.1.1, however version 9.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

# But then I get this :
tim@linus:~/Downloads$ which pip
/home/tim/.local/bin/pip

# and this:
tim@linus:~/Downloads$ pip --version
pip 9.0.3 from /home/tim/.local/lib/python2.7/site-packages (python 2.7)

Not sure how to resolve - please advise,
thanks

--
Tim



When pip 8.1.1 yells at you about version, are you installing something 
--user for yourself, or are you using sudo to install it systemwide. 
Because 'sudo which pip' is probably still pointed to the APT installed one.


--
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: Getting "LazyImporter' object is not callable" error when trying to send email using python smtplib

[Sum]

Thanks Steve for your inputs.
Now I am able to run the code successfully.

# Made changes to import statements as below:
from email.mime.base import MIMEBase
from email.mime.text import MIMEText


Apologies for the typo and indentation error in above mail.

Regards,
Sumit


On Mon, Mar 26, 2018 at 6:04 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Mon, 26 Mar 2018 16:47:26 +0530, Sum wrote:
>
> > Hi,
> >
> > Getting "LazyImporter' object is not callable" error. I have enabled
> > allow less secure app setting in sender gmail.
> >
> > Code :
>
> The code you show is not the same as the code you are actually running.
> The error message you give says:
>
> File "test_mail.py", line 64, in
>   send_email(to, SUBJECT, TEXT, attachment_file)
> File "test_mail.py", line 24, in send_email
>   msg.attach(MIMEText(text))
> TypeError: 'LazyImporter' object is not callable
>
>
> Notice the quoted line 24. Here it is again:
>
> msg.attach(MIMEText(text))
>
> But line 24 in the code you give us is:
>
> msg.attach(part)
>
>
> which is different. Also, you have a line of code:
>
> except smtplib.SMTPException,error::
>
> Notice the two colons at the end of the line? That's a syntax error. So
> the code you have shown us cannot possibly be the same as the code you
> are running.
>
> Please review your code, copy and paste the complete traceback, starting
> with the line "Traceback", and make sure that you have run the code you
> show us.
>
> It might help to read this page:
>
> http://sscce.org/
>
> It's written for Java programmers, but the ideas apply equally to Python.
>
>
> Thank you,
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String Formatting with new .format()

[Chris Angelico]

On Tue, Mar 27, 2018 at 2:37 AM, Ganesh Pal  wrote:
> Hi Team,
>
> Just a quick suggestion, on string formatting with .format() which of the
> below is better , given both give the same result .
>
 attempts = 1
 msg2 = "Hello"
 print "Retry attempt:{0} for error:{1}".format(attempts,msg2)
> Retry attempt:1 for error:Hello
>
> OR
>
 attempts = 1
 msg2 = "Hello"
 print "Retry attempt:{0} for error:{0}".format(attempts,msg2)
> Retry attempt:1 for error:1


Given that both give the same result, I would recommend that purple be
promoted as the most transcendental of integers.

Or maybe they're not giving the same result. I'm a little confused here.

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

Re: [OT] multicore/cpu history

[Gene Heskett]

On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote:

> On Mon, 26 Mar 2018 10:02:15 + (UTC), Steven D'Aprano
>
>  declaimed the following:
> >Hardware people can probably tell you what it is that CPUs do that
> > FPUs and GPUs don't do. Or specialised Bitcoin mining chips.
> > Whatever it is that they don't do, but CPUs do, is probably a good
> > dividing line between "CPU" and "auxiliary chip".
>
>   And then... to confuse matters...
>
>   As I recall, the bootloader on the Raspberry Pi runs on the graphics
> processor, and it sets up the memory image for Linux before passing
> control to the ARM processor.

Does that come with docs on how to change kernels in case the one you are 
running has to be rebooted 2-10 times to get the keyboard/mouse ducks 
all in a row so it doesn't randomly throw away events?
>
> --
>   Wulfraed Dennis Lee Bieber AF6VN
>   wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/



-- 
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

String Formatting with new .format()

[Ganesh Pal]

Hi Team,

Just a quick suggestion, on string formatting with .format() which of the
below is better , given both give the same result .

>>> attempts = 1
>>> msg2 = "Hello"
>>> print "Retry attempt:{0} for error:{1}".format(attempts,msg2)
Retry attempt:1 for error:Hello

OR

>>> attempts = 1
>>> msg2 = "Hello"
>>> print "Retry attempt:{0} for error:{0}".format(attempts,msg2)
Retry attempt:1 for error:1
>>>


PS : This is the silly question but I wanted to know if it really makes any
difference

I am on Python 2.7 and Linux

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

Re: Entering a very large number

[Chris Angelico]

On Mon, Mar 26, 2018 at 11:46 PM, bartc  wrote:
> On 26/03/2018 13:30, Richard Damon wrote:
>>
>> On 3/26/18 6:31 AM, bartc wrote:
>
>
>>> The purpose was to establish how such int("...") conversions compare in
>>> overheads with actual arithmetic with the resulting numbers.
>>>
>> Of course if this was done in C with a version that had builtin bignum
>> ints or an aggresive enough optimizer (or a Python that did a similar level
>> of optimizations) this function would just test the speed of starting the
>> program, as it actually does nothing and can be optimized away.
>
>
> Which is a nuisance. /You/ are trying to measure how long it takes to
> perform a task, the compiler is demonstrating how long it takes to /not/
> perform it! So it can be very unhelpful.

Yeah. It's so annoying that compilers work so hard to make your code
fast, when all you want to do is measure exactly how slow it is.
Compiler authors are stupid.

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

Synthesize a new series

[qrious]

I have a set of series of numbers. The set bears some common property about the 
series. For example, in one case, Series 1 can be the set of random number of 
odd numbers starting from 1 and Series N can be the set of random number of odd 
numbers starting from N. In another case, Series 1 can be the set of random 
number of odd numbers starting from 1, Series N can be the set of random number 
of (odd number)^N starting from 5 (arbitrary number), and so on. Each series 
can be of arbitrary length.

Even though the set members are 'similar' in properties, the exact relationship 
is not known.

I want to generate one additional member of the set that is 'similar' in 
properties with the existing one.

Questions:

1. Will Machine Learning be useful for this? If so, which specific term I 
should do a search on. Sorry for the lack of knowledge here.
2. I want to minimize the amount of coding, with preference for 0 coding. 
Which off-the-shelf tool (preference: open source and free) will be useful for 
this? If programming is needed, I would like to use Python and associated 
libraries.

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

Re: Entering a very large number

[Joe Pfeiffer]

Steven D'Aprano  writes:

> On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:
>
>> If I instead initialise C using 'C = int("288712...")', then timings
>> increase as follows:
>
> Given that the original number given had 397 digits and has a bit length 
> of 1318, I must admit to some curiosity as to how exactly you managed to 
> cast it to a C int (32 bits on most platforms).
>
> It is too big for an int, a long (64 bits), a long-long (128 bits) or 
> even a long-long-long-long-long-long-long-long-long-long-long-long-long-
> long-long-long (1024 bits), if such a thing even exists.
>
> So what exactly did you do?

Curiously, the first time I read the original post I also somehow
confused it with C code.  But no, the variable is named C, it isn't
written in the C language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using object as a class

[Steven D'Aprano]

On Mon, 26 Mar 2018 07:31:06 -0500, D'Arcy Cain wrote:

> Is this behaviour (object not quite like a class) documented anywhere?

It's exactly like a class. It's an immutable class. You are making 
assumptions about what classes must be able to do.


> Does anyone know the rationale for this if any?

object is intended as the base class for all others. As such, it is 
absolutely dead simple, with no state and very few methods other than 
those required by everything. The usual way we use object instances is as 
identity-objects: objects with (almost) no behaviour other than their 
identity:

SENTINEL = object()
# later
if obj is SENTINEL: ...

A bit like None.

The usual way to get what you want is a simple subclass of object, but 
even more convenient:

py> from types import SimpleNamespace
py> x = SimpleNamespace(x=1, y=2, z=3)
py> x
namespace(x=1, y=2, z=3)




-- 
Steve

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

Re: Using object as a class

[Paul Moore]

In fact, object acts just like a user-defined class, with __slots__
set to empty:

>>> class MyObj(object):
... __slots__ = ()
...
>>> o = MyObj()
>>> o.x = 3
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'MyObj' object has no attribute 'x'

See https://docs.python.org/3.6/reference/datamodel.html#slots

IIRC, most built in objects (of which object is one) behave as if they
have __slots__ set (they don't actually, because they are written in
C, but the effect is the same).

Paul

On 26 March 2018 at 13:31, D'Arcy Cain  wrote:
> It's called a super class but it doesn't quite work like a normal class.
>
 OBJ = object()
 OBJ.x = 3
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'object' object has no attribute 'x'
>
> I can fix this by creating a NULL class.
>
 class NullObject(object): pass
> ...
 OBJ = NullObject()
 OBJ.x = 3
 OBJ.x
> 3

>
> Is this behaviour (object not quite like a class) documented anywhere?
> Does anyone know the rationale for this if any?
>
> In case anyone wants to know why I am doing this, sometimes I simply
> want an object to hold values that I can pass around.  I don't need
> methods and I don't always know what variables I am going to need.
>
> And yes, I know that dict is the usual way to do this.
>
> --
> D'Arcy J.M. Cain
> Vybe Networks Inc.
> http://www.VybeNetworks.com/
> IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Entering a very large number

[bartc]

On 26/03/2018 13:30, Richard Damon wrote:

On 3/26/18 6:31 AM, bartc wrote:


The purpose was to establish how such int("...") conversions compare 
in overheads with actual arithmetic with the resulting numbers.


Of course if this was done in C with a version that had builtin bignum 
ints or an aggresive enough optimizer (or a Python that did a similar 
level of optimizations) this function would just test the speed of 
starting the program, as it actually does nothing and can be optimized 
away.


Which is a nuisance. /You/ are trying to measure how long it takes to 
perform a task, the compiler is demonstrating how long it takes to /not/ 
perform it! So it can be very unhelpful.


Hence my testing with CPython 3.6, rather than on something like PyPy 
which can give results that are meaningless. Because, for example, real 
code doesn't repeatedly execute the same pointless fragment millions of 
times. But a real context is too complicated to set up.


 Yes, something like this can beused to measure the base time to do
something, but the real question should be is that time significant 
compared to the other things that the program is doing, Making a 200x 
improvement on code that takes 1% of the execution time saves you 
0.995%, not normally worth it unless your program is currently running 
at 100.004% of the allowed (or acceptable) timing, if acceptable timing 
can even be defined that precisely.


I'm usually concerned with optimisation in a more general sense than a 
specific program.


Such a with a library function (where you don't know how it's going to 
be used); or with a particular byte-code in an interpreter (you don't 
know how often it will be encountered); or a generated code sequence in 
a compiler.


But even 200x improvement on something that takes 1% of the time can be 
worthwhile if it is just one of dozens of such improvements. Sometimes 
these small, incremental changes in performance can add up.


And even if it was just 1%, the aggregate savings across one million 
users of the program can be substantial, even if the individuals won't 
appreciate it. 1% extra battery life might be a handy five minutes for 
example.


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

Re: Entering a very large number

[Steven D'Aprano]

On Mon, 26 Mar 2018 11:45:33 +0100, bartc wrote:

> Similar overheads occur when you use string=>int even on small numbers:
> 
> This code:
> 
>  C = int("12345")
>  D = C+C  # or C*C; about the same results
> 
> takes 5 times as long (using my CPython 3.6.x on Windows) as:
> 
>  C = 12345
>  D = C+C
> 
> Your arguments that this doesn't really matter would equally apply here.

Efficiency-wise, you are correct.

But that's not why we (well, some of us...) write C = 12345 instead of 

C = int("12345")

or 
C = (((int("1")*10 + int("2"))*10 + int("3"))*10 + int("4")
 )*10 + int(5)

Even that second one would probably be an insignificant runtime cost for 
99% of real applications.

No, the reason why we write C = 12345 is because it is the most straight-
forward, natural, idiomatic way to assign 12345, and therefore the least 
surprising and easiest to read and understand. The fact that it is also 
faster is a bonus.

Contrariwise, we *do* write:

D = Decimal("12.345")

and similar idioms.

When it comes to short integer values, there's no possible benefit to 
either readability or performance to write it as a string and convert. It 
is *harder* to read int("12345") than simply 12345.

But when it comes to huge ints with hundreds or thousands of digits, 
that's not the case. In the absence of special syntax to support huge 
ints, the most readable way to include a HUGE literal int is as a string, 
and then perform our own processing:

C = """123 456 789 012 345 678 901 234 567 ...
   567 890 123 456 789 012 345 678 901 ...
   ..."""
C = parse_and_convert(C)

and so on. As the author, you get to decide how many extra work you are 
prepared to do in the conversion step, in order to buy you extra 
readability. For example, formatting the number in groups of three digits.

Now, if we had a specialist language that was focused specifically on 
huge ints with thousands of digits, then it might be worth building in 
special syntax for it. Python is already half-way there: recent versions 
support using underscores in ints to make it easier to group digits. All 
we really need now is support for multi-line ints.

But for a generalist language like Python, it's probably not too clever 
to try to support ever smaller niche requirements. Especially for an open 
source project, manpower is always at short supply. There are far more 
important priorities to attend to.


-- 
Steve

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

Re: Getting "LazyImporter' object is not callable" error when trying to send email using python smtplib

[Steven D'Aprano]

On Mon, 26 Mar 2018 16:47:26 +0530, Sum wrote:

> Hi,
> 
> Getting "LazyImporter' object is not callable" error. I have enabled
> allow less secure app setting in sender gmail.
> 
> Code :

The code you show is not the same as the code you are actually running. 
The error message you give says:

File "test_mail.py", line 64, in 
  send_email(to, SUBJECT, TEXT, attachment_file) 
File "test_mail.py", line 24, in send_email
  msg.attach(MIMEText(text))
TypeError: 'LazyImporter' object is not callable


Notice the quoted line 24. Here it is again:

msg.attach(MIMEText(text))

But line 24 in the code you give us is:

msg.attach(part)


which is different. Also, you have a line of code:

except smtplib.SMTPException,error::

Notice the two colons at the end of the line? That's a syntax error. So 
the code you have shown us cannot possibly be the same as the code you 
are running.

Please review your code, copy and paste the complete traceback, starting 
with the line "Traceback", and make sure that you have run the code you 
show us.

It might help to read this page:

http://sscce.org/

It's written for Java programmers, but the ideas apply equally to Python.


Thank you,



-- 
Steve

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

Using object as a class

[D'Arcy Cain]

It's called a super class but it doesn't quite work like a normal class.

>>> OBJ = object()
>>> OBJ.x = 3
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'object' object has no attribute 'x'

I can fix this by creating a NULL class.

>>> class NullObject(object): pass
...
>>> OBJ = NullObject()
>>> OBJ.x = 3
>>> OBJ.x
3
>>>

Is this behaviour (object not quite like a class) documented anywhere?
Does anyone know the rationale for this if any?

In case anyone wants to know why I am doing this, sometimes I simply
want an object to hold values that I can pass around.  I don't need
methods and I don't always know what variables I am going to need.

And yes, I know that dict is the usual way to do this.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Entering a very large number

[Richard Damon]

On 3/26/18 6:31 AM, bartc wrote:

On 26/03/2018 10:34, Steven D'Aprano wrote:

On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:



If I instead initialise C using 'C = int("288712...")', then timings
increase as follows:


Given that the original number given had 397 digits and has a bit length
of 1318, I must admit to some curiosity as to how exactly you managed to
cast it to a C int (32 bits on most platforms).

It is too big for an int, a long (64 bits), a long-long (128 bits) or
even a long-long-long-long-long-long-long-long-long-long-long-long-long-
long-long-long (1024 bits), if such a thing even exists.


So what exactly did you do?


I'm not sure why you think the language C came into it. I did this:

def fn():
    C = int(
    "28871482380507712126714295971303939919776094592797"
    "22700926516024197432303799152733116328983144639225"
    "94197780311092934965557841894944174093380561511397"
    "4215424169339729054237110027510420801349667317"
    "5515285922696291677532547505856101949404200039"
    "90443211677661994962953925045269871932907037356403"
    "22737012784538991261203092448414947289768854060249"
    "76768122077071687938121709811322297802059565867")

#   C = 2887148238050771212671429... [truncated for this post]

    D=C+C

for i in range(100):
    fn()

The purpose was to establish how such int("...") conversions compare 
in overheads with actual arithmetic with the resulting numbers.


Of course if this was done in C with a version that had builtin bignum 
ints or an aggresive enough optimizer (or a Python that did a similar 
level of optimizations) this function would just test the speed of 
starting the program, as it actually does nothing and can be optimized 
away. Yes, something like this can beused to measure the base time to do 
something, but the real question should be is that time significant 
compared to the other things that the program is doing, Making a 200x 
improvement on code that takes 1% of the execution time saves you 
0.995%, not normally worth it unless your program is currently running 
at 100.004% of the allowed (or acceptable) timing, if acceptable timing 
can even be defined that precisely.


--
Richard Damon

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

Re: Entering a very large number

[Richard Damon]

On 3/26/18 6:45 AM, bartc wrote:

On 26/03/2018 03:35, Richard Damon wrote:

On 3/25/18 9:37 PM, bartc wrote:


So the overhead /can/ be substantial, and /can/ be significant 
compared with doing bignum calculations.


Of course, once initialised, C might be used a hundred times, then 
the overhead is less significant. But it is not small enough to just 
dismiss.


And my point is that writing a program to just add or multiply once 
two FIXED big long numbers (since they are in the source code, that 
seems fixed), a million times seems  unlikely (and even then the cost 
isn't that bad, since that sounds like a run once program).


Similar overheads occur when you use string=>int even on small numbers:

This code:

    C = int("12345")
    D = C+C  # or C*C; about the same results

takes 5 times as long (using my CPython 3.6.x on Windows) as:

    C = 12345
    D = C+C

Your arguments that this doesn't really matter would equally apply here.

Yet you don't see Python code full of 'int("43")' instead of just '43' 
on the basis that the extra overhead is not significant, as the 
program might be run only once.


A slightly worrying attitude in a language that has issues with 
performance, but no longer a surprising one.


Strawman. The original argument was that there was sufficient clarity 
grounds to want to express the big number as a string. That base 
argument doesn't hold here, and in fact for small number the construct 
clearly makes the code less clear, so the construct fails there. If the 
numbers were formatted in a way that using a string, and doing some 
manipulations on it first, and then converting made sense, you might be 
able to make the argument, but then again it comes down to efficiency vs 
clarity, and for that, as long as efficiency hasn't suffered enough to 
start to become a correctness issue, clarity has an edge.


--
Richard Damon

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

Re: Entering a very large number

[Steven D'Aprano]

On Mon, 26 Mar 2018 11:31:22 +0100, bartc wrote:

> On 26/03/2018 10:34, Steven D'Aprano wrote:

>> So what exactly did you do?
> 
> I'm not sure why you think the language C came into it.

My misunderstanding. Sorry.


-- 
Steve

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

Getting "LazyImporter' object is not callable" error when trying to send email using python smtplib

[Sum]

Hi,

Getting "LazyImporter' object is not callable" error.
I have enabled allow less secure app setting in sender gmail.

Code :

import smtplib
from email import MIMEBase
from email import MIMEText
from email.mime.multipart import MIMEMultipart
from email import Encoders
import os

def send_email(to, subject, text, filenames):
try:
gmail_user = 'x...@gmail.com'
gmail_pwd = ''

msg = MIMEMultipart()
msg['From'] = gmail_user
msg['To'] = ", ".join(to)
msg['Subject'] = subject
msg.attach(MIMEText(text))

for file in filenames:
part = MIMEBase('application', 'octet-stream')
part.set_payload(open(file, 'rb').read())
Encoders.encode_base64(part)
part.add_header('Content-Disposition', 'attachment;
filename="%s"'% os.path.basename(file))
msg.attach(part)

mailServer = smtplib.SMTP("smtp.gmail.com:465")
mailServer.ehlo()
mailServer.starttls()
mailServer.ehlo()
mailServer.login(gmail_user, gmail_pwd)
mailServer.sendmail(gmail_user, to, msg.as_string())
mailServer.close()
print('successfully sent the mail')

except smtplib.SMTPException,error::
print str(error)

if __name__ == '__main__':
attachment_file = ['t1.txt','t2.csv']
to = "xxx...@gmail.com"
TEXT = "Hello everyone"
SUBJECT = "Testing sending using gmail"

send_email(to, SUBJECT, TEXT, attachment_file)


Getting below error :
File "test_mail.py", line 64, in send_email(to, SUBJECT, TEXT,
attachment_file) File "test_mail.py", line 24, in send_email
msg.attach(MIMEText(text)) TypeError: 'LazyImporter' object is not callable
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Accessing parent objects

[Antoon Pardon]

On 26-03-18 10:52, Ben Finney wrote:
> Antoon Pardon  writes:
>
>> But did they start up cleaning the standard library yet? I'll confess
>> I'm only using 3.5 but when I go through the standard library I see a
>> lot of classes still using the old style of calling the parant method,
>> which makes it more difficult to use in a multiple inheritance scheme.
>> Those that don't inheret, don't call super themselves, which makes
>> them also more difficult to use in a multiple inheritance scheme.
> Yes, there are large areas of the Python standard library that were
> written before Python 3 features, and some of those are thus less good
> than they could be.
>
> The solution is, as always: Someone needs to identify (in a bug report)
> what specifically should be improved; someone needs to come up with a
> specific implementation of that improvement (in a merge request, with
> unit tests); someone needs to maintain that code in the standard
> library on an ongoing basis.

I would have thought there is already someome maintaining the standard
library code. I would also have thought that a rather thorough review
of the standard library code would have been part of the upgrade to python3.

> Feel free to take on any of that work; this is work that can be done by
> anyone in the Python community, we don't need to wait.
>
After having seen Raymond Hettingers talk: Super considered super!(*) My 
impression
is that the developers wouldn't be interested in such a redesign. The idea I get
away from it is that you can do what needs to be done, you just need to wrap
the not cooperating standard library classes into ones that do the cooperation
for you.

(*) https://www.youtube.com/watch?v=EiOglTERPEo&spfreload=1

-- 
Antoon.

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

Re: Entering a very large number

[bartc]

On 26/03/2018 03:35, Richard Damon wrote:

On 3/25/18 9:37 PM, bartc wrote:


So the overhead /can/ be substantial, and /can/ be significant 
compared with doing bignum calculations.


Of course, once initialised, C might be used a hundred times, then the 
overhead is less significant. But it is not small enough to just dismiss.


And my point is that writing a program to just add or multiply once two 
FIXED big long numbers (since they are in the source code, that seems 
fixed), a million times seems  unlikely (and even then the cost isn't 
that bad, since that sounds like a run once program).


Similar overheads occur when you use string=>int even on small numbers:

This code:

C = int("12345")
D = C+C  # or C*C; about the same results

takes 5 times as long (using my CPython 3.6.x on Windows) as:

C = 12345
D = C+C

Your arguments that this doesn't really matter would equally apply here.

Yet you don't see Python code full of 'int("43")' instead of just '43' 
on the basis that the extra overhead is not significant, as the program 
might be run only once.


A slightly worrying attitude in a language that has issues with 
performance, but no longer a surprising one.


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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Sun, 25 Mar 2018 19:16:12 -0700, Rick Johnson wrote:

> On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote:
> 
>> [supposed "fix" to the sample script snipped]
>>
>> You know Rick, every time I start to think that talking to you like an
>> adult might result in a productive and intelligent conversation, you
>> pull a stunt like this.  Once I recover from laughing at your inability
>> to read a simple eight line Ruby script, and then laughing even harder
>> at your inability to tell the difference between a string in Ruby and
>> an actual function call, I *might* come back and read the rest of your
>> post.

[...]

> If not, then explain to this group exactly how i failed.


Rick, you're supposedly familiar with Ruby. And yet, you didn't notice 
that your supposed "fix" didn't touch any executable code, all it did was 
modify the strings being printed. Because of this "fix", the printed 
strings no longer match the code being executed, but the strange, 
inconsistent behaviour still occurs.

For the benefit of those who aren't Ruby experts, the code I used before 
(see below) defines a function called "a", then prints four ways of 
calling that function that differ only in whitespace. For example:

print "a + b => ", (a + b), "\n"


prints the string "a + b", then calls a and adds b using the same syntax 
as that shown in the string, then prints a newline.

The kicker is that out of these four legal, parenthesis-free ways of 
calling function a, *three* of them interpret the expression as:

call a with no arguments
then add b using the binary plus operator

but the last, differing only in whitespace, interprets it as:

call a with a single argument, unary-plus b


Here's the code again:


# --- cut ---
def a(x=4)
x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"
# --- cut ---

and your "fix" was to modify the *strings* without touching the actual 
function calls. Well done Rick.

Of course we can solve the problem by always using parentheses when 
making function calls. But that misses the point that Ruby allows this 
inconsistency in the first place.



-- 
Steve

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

Re: Entering a very large number

[bartc]

On 26/03/2018 10:34, Steven D'Aprano wrote:

On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:



If I instead initialise C using 'C = int("288712...")', then timings
increase as follows:


Given that the original number given had 397 digits and has a bit length
of 1318, I must admit to some curiosity as to how exactly you managed to
cast it to a C int (32 bits on most platforms).

It is too big for an int, a long (64 bits), a long-long (128 bits) or
even a long-long-long-long-long-long-long-long-long-long-long-long-long-
long-long-long (1024 bits), if such a thing even exists.


So what exactly did you do?


I'm not sure why you think the language C came into it. I did this:

def fn():
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"5515285922696291677532547505856101949404200039"
"90443211677661994962953925045269871932907037356403"
"22737012784538991261203092448414947289768854060249"
"76768122077071687938121709811322297802059565867")

#   C = 2887148238050771212671429... [truncated for this post]

D=C+C

for i in range(100):
fn()

The purpose was to establish how such int("...") conversions compare in 
overheads with actual arithmetic with the resulting numbers.


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

Re: Accessing parent objects

[Steven D'Aprano]

On Mon, 26 Mar 2018 10:43:25 +0200, Antoon Pardon wrote:

> But did they start up cleaning the standard library yet? I'll confess
> I'm only using 3.5 but when I go through the standard library I see a
> lot of classes still using the old style of calling the parant method,
> which makes it more difficult to use in a multiple inheritance scheme.
> Those that don't inheret, don't call super themselves, which makes them
> also more difficult to use in a multiple inheritance scheme.

Ah, that's a separate question! And it's a good observation.

You are right that there is a lot of legacy code in the std lib that 
doesn't use super, and probably should. Fixing that is probably a good 
project for some kindly volunteer wanting to get into Python bug-
fixing :-)

But you can usually fix that in your own code with a simple adaptor class 
that delegates to the old-style class. See for example:

https://code.activestate.com/recipes/577721

https://rhettinger.wordpress.com/2011/05/26/super-considered-super/


> One of the problems with this is that when you go through the mro you
> will ultimatly end up calling object.method(self, spam, eggs, cheese)
> which will thrown an exception like: AttributeError: 'super' object has
> no attribute 'method'

Why in the name of all the gods would you call super() on a method you 
aren't inheriting from a superclass???

I'm sorry if my example was inaccurate or misleading, but please be 
reasonable. Calling super in a method which you aren't overloading is not 
a reasonable thing to do.


> So I find your example misleading. It is just one step, and you need a
> carefully designed hierarchy to make it work correctly and incorporating
> standard library classe into that hierarchy is not self-evident.

You *always* need a carefully designed hierarchy.

super or no super, single inheritance or delegation or multiple 
inheritance, you can't expect to just randomly throw classes together in 
a slap-dash manner and have them work.



-- 
Steve

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

Re: [OT] multicore/cpu history

[Steven D'Aprano]

On Mon, 26 Mar 2018 10:03:43 +1100, Chris Angelico wrote:

> At what point does it change from being two CPUs to being one CPU and
> one auxiliary processing unit?

When someone writes an OS that will run on the "auxiliary processing 
unit" alone, then it's probably time to start calling it a CPU :-)


> Back in the 80s and early 90s, the
> auxiliary was most likely to be a floating-point unit; today, it'd be a
> graphics chip. But it could just as easily be a Lisp chip.

Or a Forth chip.

Hardware people can probably tell you what it is that CPUs do that FPUs 
and GPUs don't do. Or specialised Bitcoin mining chips. Whatever it is 
that they don't do, but CPUs do, is probably a good dividing line between 
"CPU" and "auxiliary chip".


-- 
Steve

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

Re: Accessing parent objects

[Steven D'Aprano]

On Mon, 26 Mar 2018 10:02:23 +0200, Antoon Pardon wrote:

>> The trick is to use new-style classes that inherit from object, and
>> avoid the old-style classes that don't:
>>
>> # Good
>> class Spam(object):
>> ...
>>
>> # Not so good
>> class Spam:
>> ...
> 
> How good is that when almost all classes in the standard library are old
> style classes?

I'm glad you asked!

I presume you're talking about Python 2, since the standard library of 
Python 3 is 100% "new-style".

In Python 2, there are 76 new-style classes in the builtins, most of 
which can be subclassed:


py> import __builtin__ as builtins
py> sum(type(obj) is type for obj in builtins.__dict__.values())
76

As a very quick-and-dirty test, I counted classes in the stdlib that 
subclassed object:

[steve@ando python2.7]$ grep "class .*(object)" *.py | wc -l
55
[steve@ando python2.7]$ grep "class .*(object)" */*.py | wc -l
562

plus another 47 for list and int -- I didn't bother counting subclasses 
of dict, tuple, str, etc). So, in round figures, there are about 700 new 
style class in the Python 2.7 std lib.

As a similarly quick-and-dirty test, I counted old-style classes:


[steve@ando python2.7]$ grep "\Wclass .*[^\(\)]*:" *.py | grep -v -F "(" 
| wc -l
42
[steve@ando python2.7]$ grep "\Wclass .*[^\(\)]*:" */*.py | grep -v -F 
"(" | wc -l
365


I daresay that's an under-estimate, so let's double it to be safe.

So we have (in round figures) about 700 new-style classes versus 800 old-
style classes in Python 2.7.

I'm no mathematician[1] but that hardly seems like "almost all" old-style 
classes to me.

We can quibble about the exact numbers, and about which classes are the 
most commonly subclassed, and how many false positives there are from 
using grep, but however you look at it, it is clear that a significant 
portion of stdlib classes are new-style.





[1] Actually, I am.

-- 
Steve

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

Re: Entering a very large number

[Steven D'Aprano]

On Mon, 26 Mar 2018 02:37:44 +0100, bartc wrote:

> Calling a function that sets up C using 'C = 288714...' on one line, and
> that then calculates D=C+C, takes 0.12 seconds to call 100 times.
> 
> To do D=C*C, takes 2.2 seconds (I've subtracted the function call
> overhead of 0.25 seconds; there might not be any function call).

Bart, this is a contrived example that really proves nothing. This is 
literally the sort of premature optimization that Knuth etc so frequently 
warn about. In *almost any* real program, you're not going to be 
calculating C+C over and over and over and over again, millions of times 
in a row, while doing *literally* nothing else.

If your point is that, *hypothetically*, there could be some amazingly 
unlikely set of circumstances where that's exactly what I will need to 
do, then fine, I'll deal with those circumstances when it happens and not 
a moment before.

And I'll probably deal with it by calculating C+C in Python, then hard-
coding D= that number, reducing the runtime cost of the addition to zero.


> If I instead initialise C using 'C = int("288712...")', then timings
> increase as follows:

Given that the original number given had 397 digits and has a bit length 
of 1318, I must admit to some curiosity as to how exactly you managed to 
cast it to a C int (32 bits on most platforms).

It is too big for an int, a long (64 bits), a long-long (128 bits) or 
even a long-long-long-long-long-long-long-long-long-long-long-long-long-
long-long-long (1024 bits), if such a thing even exists.


So what exactly did you do?



-- 
Steve

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

Re: Accessing parent objects

[Ben Finney]

Antoon Pardon  writes:

> But did they start up cleaning the standard library yet? I'll confess
> I'm only using 3.5 but when I go through the standard library I see a
> lot of classes still using the old style of calling the parant method,
> which makes it more difficult to use in a multiple inheritance scheme.
> Those that don't inheret, don't call super themselves, which makes
> them also more difficult to use in a multiple inheritance scheme.

Yes, there are large areas of the Python standard library that were
written before Python 3 features, and some of those are thus less good
than they could be.

The solution is, as always: Someone needs to identify (in a bug report)
what specifically should be improved; someone needs to come up with a
specific implementation of that improvement (in a merge request, with
unit tests); someone needs to maintain that code in the standard
library on an ongoing basis.

Feel free to take on any of that work; this is work that can be done by
anyone in the Python community, we don't need to wait.

-- 
 \   “… whoever claims any right that he is unwilling to accord to |
  `\ his fellow-men is dishonest and infamous.” —Robert G. |
_o__)   Ingersoll, _The Liberty of Man, Woman and Child_, 1877 |
Ben Finney

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

Re: Accessing parent objects

[Antoon Pardon]

On 25-03-18 06:29, Steven D'Aprano wrote:
> Python 3 is now six point releases in (and very soon to have a seventh,
> 3.7 being in beta as we speak). It is stable, feature-rich, and a joy to 
> work in. As well as a heap of great new features, there have been a 
> metric tonne of performance improvements, making Python 3 faster than 2.7 
> for many tasks, e.g.

But did they start up cleaning the standard library yet? I'll confess I'm
only using 3.5 but when I go through the standard library I see a lot of
classes still using the old style of calling the parant method, which
makes it more difficult to use in a multiple inheritance scheme. Those
that don't inheret, don't call super themselves, which makes them also
more difficult to use in a multiple inheritance scheme.
 

> For comparison, here's how Python's super works in 3.x:
>
> def method(self, spam, eggs, cheese):
> result = super().method(spam, eggs, cheese)
>
> In other words, you must explicitly state the method you are calling, and 
> give the arguments you want to pass on. Of course you can manipulate or 
> remove those arguments as needed, or add new ones:

One of the problems with this is that when you go through the mro you will
ultimatly end up calling object.method(self, spam, eggs, cheese) which will
thrown an exception like: AttributeError: 'super' object has no attribute 
'method'

So I find your example misleading. It is just one step, and you need
a carefully designed hierarchy to make it work correctly and incorporating
standard library classe into that hierarchy is not self-evident.

-- 
Antoon

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

Re: Accessing parent objects

[Ben Finney]

Antoon Pardon  writes:

> On 25-03-18 00:54, Steven D'Aprano wrote:
> > The trick is to use new-style classes that inherit from object, and
> > avoid the old-style classes that don't:
> >
> > # Good
> > class Spam(object):
> > ...
> >
> > # Not so good
> > class Spam:
> > ...
>
> How good is that when almost all classes in the standard library are
> old style classes?

That's a vague question. So, a vague answer: When that is the case, it's
quite good.

Is that satisfactory? Or would you care to elaborate on what the
question is?

-- 
 \  “Natural catastrophes are rare, but they come often enough. We |
  `\   need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 |
_o__)  |
Ben Finney

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

Re: Accessing parent objects

[Antoon Pardon]

On 25-03-18 00:54, Steven D'Aprano wrote:
>
> There's nothing wrong with super() in Python 2. You just have to 
> understand what you're doing. It's still the right solution for doing  
> inheritance the right way.
>
> ... 
>
> The trick is to use new-style classes that inherit from object, and avoid 
> the old-style classes that don't:
>
> # Good
> class Spam(object):
> ...
>
> # Not so good
> class Spam:
> ...

How good is that when almost all classes in the standard library are old style 
classes?

-- 
Antoon


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