Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov 
wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.

No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid readability at
a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.

> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.

I thought the proposal was clear and succinct. "When [lambda expressions]
are directly assigned to a variable, Python would use the variable name as
the function name." That's all. I don't know where you got the idea I was
proposing "to get rid of assignment".

Maybe it was from my talk of implementing this by replacing the assignment
with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates a
function and assigns it to a name. The only difference between the original
assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just makes
the direct lambda assignment and the def "assignment" to be fully
equivalent.

> Note that
>
> foo.bar = baz
>
> and
>
> foo[bar] = baz

I wrote "directly assigned to a variable", not to an attribute or an item.
These are not part of the suggestion.

> Do you propose to desugar it into a method/function call and to get rid
> of assignments in the language completely? Will the user be able to
> override this method? Something like:
>
> setvar("foo", bar)  # desugaring of foo = bar

No, this is entirely unrelated to what I suggested.

> I am so perplexed by the proposed behaviour of `f = lambda...`, that i
> need to ask the followng: am i right to expact that

I'm not going to address what these would do because I haven't developed
the idea to this level of detail, nor do I intend to. It was just an idea
put forth to address the complaint that lambda functions assigned to
variables don't get properly named, as well as the obstacle that the
proposed "f(x) = ..." syntax not only explicitly refuses to address this,
but potentially makes the problem worse by making lambda assignment more
attractive without doing anything to actually name them. I have no
expectation of writing a PEP for it.

> I suppose in any case that
>
> return lambda x: 
>
> and
>
> result = lambda x: 
> return result
>
> would not return the same result, which is not what i want.

Correct, the first would return a function with the name "" (as it
does now), while the second would return a function with the name "result".
Whether or not that is more useful than "" in this case is up to
the reader.

> I tried to imagine what semantics of the language could cause your
> proposed behaviour of `f = lambda...` and couldn't think of anything
> short of breaking the language.

I'm fairly sure the language would continue to function just fine. It
creates a gotcha to be sure, but it's far from being the only one, or even
the biggest one that has to do with lambdas (that award surely goes to the
behavior of lambda closures created in a loop, which comes up on this list
with some regularity).
-- 
https://mail.python.org/mailman/listinfo/python-list

Generator definition syntax (was: Syntax for one-line "nonymous" functions)

[Alexey Muranov]

On mar., Apr 2, 2019 at 4:31 AM, python-list-requ...@python.org wrote:
Re: ">> Neither i like how a function magically turns into a 
generator if the

 keyword `yield` appears somewhere within its definition.


 I agree, there should have been a required syntactic element on the 
"def"
 line as well to signal it immediately to the reader. It won't stop 
me from using them, though."


One way to save people looking at the code from having to look 
through a function for a yield statement to see if it is a generator 
would be to add a """doc string""" immediately after the function 
def, saying that it is a generator
and describing what it does.  I realize I'm calling on the programmer 
to address this issue by adding doc strings.  Nonetheless adding doc 
strings is a good habit to get in to.

--- Joseph S.


And even if Python did not have docstrings, the programmer could still 
use comments to tell a fellow programmer what kind of code the fellow 
programmer is looking at. Even languages like Brainfuck have comments 
:).


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Tue, Apr 2, 2019 at 6:04 PM Ian Kelly  wrote:
> > Note that
> >
> > foo.bar = baz
> >
> > and
> >
> > foo[bar] = baz
>
> I wrote "directly assigned to a variable", not to an attribute or an item.
> These are not part of the suggestion.

So what's the advantage over just using def?

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com>

wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.

No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid 
readability at

a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.


Since i understand that the "super() magic" is just evaluation in a 
predefined environment, it does not look so very magic.  I do not know 
if Python can already manipulate blocks of code and environments as 
first-class objects, but in any case this does not look to be too far 
from the its normal behaviour/semantics.


Moreover, without this "magic", `super()` would have just produced an 
error.  So this magic did not change behaviour of something that worked 
before, it made "magically" work something that did not work before 
(but i am still not excited about it).


On the contrary, i have no idea of how in the current semantics 
executing an assignment can mutate the assigned value.



> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.

I thought the proposal was clear and succinct. "When [lambda 
expressions]
are directly assigned to a variable, Python would use the variable 
name as
the function name." That's all. I don't know where you got the idea I 
was

proposing "to get rid of assignment".


I suppose we use the term "assignment operation" differently.  By 
assignment i mean evaluating the expressions in the right-hand side and 
assigning (binding?) the value to the variable or location described in 
the left-hand side. I believed this was the usual meaning of 
"assignment"...


The behaviour you describe cannot happen during assignment in this 
sense.


Maybe it was from my talk of implementing this by replacing the 
assignment

with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates 
a
function and assigns it to a name. The only difference between the 
original

assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just 
makes

the direct lambda assignment and the def "assignment" to be fully
equivalent.


`def` is not an assignment, it is more than that.

Alexey.


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

Re: Losing words

[John Doe]

On 2019-04-01, Paul Rubin  wrote:
> John Doe  writes:
>> sendall also is not sending a whole sentence. 
>
> Have you observed that with something like wireshark?
>


I was about colon ":" before message with a colon a whole message is
" before message with a colon a whole message is sent.
 .
 
> Also, to do a nonterminating loop in Python, use "while True".  Your use
> of tail recursion is traditional in functional programming but in Python
> it will end up leaking memory by pushing a new stack frame at each
> recursive call.
>
And here I'm stuck indeed.

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

DeprecationWarning in Python 3.6 and 3.7

[אורי]

Hi,

Please look at this issue:
DeprecationWarning in Python 3.6 and 3.7


I tried to upgrade to the latest virtualenv (virtualenv==16.4.3) in the
tests but the tests still fail in Python 3.6 and 3.7 with
the DeprecationWarning:

(with Pillow==5.4.1):
https://travis-ci.org/speedy-net/speedy-net/builds/514284524

(with Pillow==6.0.0):
https://travis-ci.org/speedy-net/speedy-net/builds/514595887

What is the problem?

אורי
u...@speedy.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How call method from a method in same class?

[dboland9]

Cameron,

Again, thanks for the help. I agree with everything you wrote, but... The code 
was thrown together to produce the error so I could illustrate the problem. It 
was by design junk. But it did produce the error, I got some great answers to 
my situation, so I am very grateful for the help.

Dave,
April 1, 2019 10:30 PM, "Cameron Simpson" mailto:c...@cskk.id.au)> wrote:
 On 01Apr2019 22:02, Dave mailto:dbola...@offilive.com)> wrote:
 As classes get more complex, it is good to call a function to do some >of the 
processing, and make
the code easier to follow. My question is >how to do that? I've attached some 
silly code to
illustrate the >point. The error is: name 'validScale' is not defined. Well, 
yes it >is, but maybe
not the correct way. Suggestions? 

It is and it isn't. See below:
 class TempConverter():
""" Temperature Converter converts a tempeature from one scale
to another scale. For example: 32, F, C will return
0 degrees C
""" 

[...]
 def validScale(self, scaleName):
if scaleName.upper == 'F' or 'C' or 'K':
return True
else:
return False

def convertTemp(self):
""" Converts temperature scale if scales valid."""
if validScale(self.scale):
scaleValid = True 

[...]

It is an instance method, so:

if self.validScale(self.scale)

would resolve the name. However, there are several things worth discussing here.

First up, validScale itself returns a Boolean, so just return the test result. 
Change:

if scaleName.upper == 'F' or 'C' or 'K':
return True
else:
return False

into:

return scaleName.upper == 'F' or 'C' or 'K'

Second, the condition is buggy. You want this:

return scaleName.upper() in ('F', 'C', 'K')

i.e. you need to call (the "()") the .upper method, and you need to check if 
the result is in your
collection of valid results.

This expression:

value == A or B or C

means: True if value == A, otherwise B if B is true, otherwise C.

The next thing to observe is that you're testing whether self.scale is valid. 
Normal practice would
be to make that test in __init__, and raise a ValueError if it is not so:

def __init__(self, .scale...):
if scale.upper() not in ('F', 'C', 'K'):
raise ValueError("invalid scale %r: expected one of F, C or K" % (scale,))
why recite the scale in the message? Because it makes the offending value 
obvious. In particular,
if for example you called this incorrectly and had the temperature in there 
instead of the scale
that will be trivial to debug from the message.

Of course, you actually want to be able to test any scal evalue for validity, 
not just the one
stuffed into your instance (.scale). So lets revisit the validScale method:

def validScale(self, scale):
return scaleName.upper() in ('F', 'C', 'K')

You'll notice that it doesn't depend in "self". Or, for that matter, the class. 
So this is a
"static" method: a function defined in the class for conceptual clarity, but 
not with any
dependence on the class itself or a particular class instance. So:

@staticmethod
def validScale(scale):
return scaleName.upper() in ('F', 'C', 'K')

In __init__, and elsewhere, you can still call this from the instance:

def __init__(self, .scale...):
if not self.validScale(scale):
raise ValueError("invalid scale %r: expected one of F, C or K" % (scale,))
You can also call this from _outside_ the class, for example for other 
validation:

scale = input("Enter a temperate scale name (F, C or K): ")
if not TempConverter.validScale(scale):
print("Bad! Bad user!")
 newScaleValid = True 

Again, validScale returns a Boolean. So you could have just gone:

newScaleValid = self.validScale(newScale)
 if scaleValid and newScaleValid:
print('Scale converted')
else:
msg = "There was and error with the scales entered.n"
msg = msg + "You entered: " + self.scale
msg = msg + ' ' 'and' + self.newScale
print(msg)

if __name__ == "__main__":
myclass = TempConverter(32, 'f', 'c')
myclass.convertTemp() 

My personal inclination would be do define a Temperature class with a convert 
function to be used
like this:

temp = Temperature(32, 'f')
tempC = temp.convert('c')

This reduces the complexity of the class and IMO makes it easier to use 
elsewhere.

BTW, you get an instance back from tempConverter(...), not a class. So don't 
call it "myclass".

Cheers,
Cameron Simpson mailto:c...@cskk.id.au)>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov 
wrote:
>
> > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov  > gmail.com>
> > wrote:
> > >
> > > I only see a superficial analogy with `super()`, but perhaps it is
> > > because you did not give much details of you suggestion.
> >
> > No, it's because the analogy was not meant to be anything more than
> > superficial. Both are constructs of syntactic magic that aid
> > readability at
> > a high level but potentially obscure the details of execution (in
> > relatively unimportant ways) when examined at a low level.
>
> Since i understand that the "super() magic" is just evaluation in a
> predefined environment, it does not look so very magic.

It's the reason why this doesn't work:

superduper = super

class A:
def f(self):
return 42

class B(A):
def f(self):
return superduper().f()

>>> B().f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in f
RuntimeError: super(): __class__ cell not found

But this does:

class C(A):
def f(self):
return superduper().f()
not super

>>> C().f()
42

I don't know, seems magical to me.

> Moreover, without this "magic", `super()` would have just produced an
> error.  So this magic did not change behaviour of something that worked
> before, it made "magically" work something that did not work before
> (but i am still not excited about it).

I'm curious how you feel about this example then (from the CPython 3.7.2
REPL; results from different Python implementations or from scripts that
comprise a single compilation unit may vary)?

>>> 372 is 372
True
>>> b = 372; b is 372
True
>>> b = 372
>>> b is 372
False

> > Maybe it was from my talk of implementing this by replacing the
> > assignment
> > with an equivalent def statement in the AST. Bear in mind that the def
> > statement is already just a particular kind of assignment: it creates
> > a
> > function and assigns it to a name. The only difference between the
> > original
> > assignment and the def statement that replaces it is in the __name__
> > attribute of the function object that gets created. The proposal just
> > makes
> > the direct lambda assignment and the def "assignment" to be fully
> > equivalent.
>
> `def` is not an assignment, it is more than that.

def is an assignment where the target is constrained to a single variable
and the expression is constrained to a newly created function object
(optionally "decorated" first with one or more composed function calls).
The only ways in which:

@decorate
def foo(blah):
return stuff

is more than:

foo = decorate(lambda blah: stuff)

are: 1) the former syntactically allows statements inside the function
body, not just expressions; 2) the former syntactically allows annotations
on the function; and 3) the former syntactically sets a function name and
the latter doesn't. In other words, all of the differences ultimately boil
down to syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[Terry Reedy]

On 4/2/2019 6:29 AM, אורי wrote:

Hi,

Please look at this issue:
DeprecationWarning in Python 3.6 and 3.7


I tried to upgrade to the latest virtualenv (virtualenv==16.4.3) in the
tests but the tests still fail in Python 3.6 and 3.7 with
the DeprecationWarning:


Which is?


(with Pillow==5.4.1):
https://travis-ci.org/speedy-net/speedy-net/builds/514284524

(with Pillow==6.0.0):
https://travis-ci.org/speedy-net/speedy-net/builds/514595887


Click on the red failure line on that page to see the test results and 
go to the end of the page and get your answer.  It has nothing to do 
with virtualenv.


Terry Jan Reedy


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

Re: python os.chdir() Windows Error 2

[grossmudda]

Ahhh now I see!! I actually was trying to import a file, now I know it´s just 
changing the directory. Next time I´d better read the description of the tool 
carefully...

Thank you so much!! You helped a lot!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[אורי]

On Tue, Apr 2, 2019 at 6:33 PM Terry Reedy  wrote:

> On 4/2/2019 6:29 AM, אורי wrote:
> > Hi,
> >
> > Please look at this issue:
> > DeprecationWarning in Python 3.6 and 3.7
> > 
> >
> > I tried to upgrade to the latest virtualenv (virtualenv==16.4.3) in the
> > tests but the tests still fail in Python 3.6 and 3.7 with
> > the DeprecationWarning:
>
> Which is?
>

I don't understand your question.


>
> > (with Pillow==5.4.1):
> > https://travis-ci.org/speedy-net/speedy-net/builds/514284524
> >
> > (with Pillow==6.0.0):
> > https://travis-ci.org/speedy-net/speedy-net/builds/514595887
>
> Click on the red failure line on that page to see the test results and
> go to the end of the page and get your answer.  It has nothing to do
> with virtualenv.
>

What do you mean? Did you see the issue I linked from GitHub? Look
at hugovk's comment from Feb. 3. [
https://github.com/python-pillow/Pillow/issues/3547#issuecomment-460037890]
He says it's related to virtualenv. Also radarhere's comment [
https://github.com/python-pillow/Pillow/issues/3547#issuecomment-451727081]
says it's virtualenv. I submitted the issue on Pillow because it occurred
when I upgraded Pillow.


>
> Terry Jan Reedy
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

אורי
u...@speedy.net
-- 
https://mail.python.org/mailman/listinfo/python-list

EuroSciPy 2019 - CfP is open

[Alexander CS Hendorf [EuroSciPy 2019]]

=

*** Apologise for multiple posting ***

Dear Colleagues,

We are delighted to invite you to join us for the 12th European Conference on 
Python in Science. 
The EuroSciPy 2019 Conference will take place from September 2 to September 6 
in Bilbao, Basque Country, Spain. 

The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and 
development of the Python language in scientific research. This event strives 
to bring together both users and developers of scientific tools, as well as 
academic research and state of the art industry.

The conference will be structured as it follows:
Sep, 2-3 : Tutorials and Hands-on
Sep, 4-5 : Main Conference
Sep, 6 : Sprints
--

TOPICS OF INTEREST:

Presentations of scientific tools and libraries using the Python language, 
including but not limited to:
Algorithms implemented or exposed in Python
Astronomy
Data Visualisation
Deep Learning & AI
Earth, Ocean and Geo Science
General-purpose Python tools that can be of special interest to the scientific 
community.
Image Processing
Materials Science
Parallel computing
Political and Social Sciences
Project Jupyter
Reports on the use of Python in scientific achievements or ongoing projects.
Robotics & IoT
Scientific data flow and persistence
Scientific visualization
Simulation
Statistics
Vector and array manipulation
Web applications and portals for science and engineering
3D Printing
---

CALL FOR PROPOSALS:

EuroScipy will accept three different kinds of contributions:

Regular Talks: standard talks for oral presentations, allocated in time slots 
of `15`, or `30` minutes, depending on your preference and scheduling 
constraints. Each time slot considers a Q&A session at the end of the talk (at 
least, 5 mins). 
Hands-on Tutorials: These are beginner or advanced training sessions to dive 
into the subject with all details. These sessions are 90 minutes long, we 
expect participants to bring their own laptop for the tutorials. 
For a sneak peak of last years tutorials, here are the videos: 
https://www.youtube.com/channel/UCruMegFU9dg2doEGOUaAWTg
Poster: EuroScipy will host two poster sessions during the two days of Main 
Conference. We warmly encourage students and participants to present their work 
and/or preliminary results as posters. 

Proposals should be submitted using the EuroScipy submission system at 
https://pretalx.com/euroscipy-2019/cfp. Submission deadline is April, 28 2019.

--

REGISTRATION & FEES:

The registration fees will be as moderate as in previous years, we'll keep you 
posted.

--

IMPORTANT DATES:


Mar 26  Call for talks, posters & tutorials
Apr 28  Submission deadline for talks and tutorials
May 20  Notifications of submission acceptance
Sept 2  Start of EuroSciPy Tutorial
Sept 4  Start of EuroSciPy Main Conference
Sept 6  EuroSciPy Sprints

--


Best regards,
EuroScipy 2019 Organising Committee,
Email: i...@euroscipy.org 
Website: http://www.euroscipy.org/2019 
twitter: @euroscipy

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On mar., Apr 2, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov 


wrote:


 > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov  gmail.com>
 > wrote:
 > >
 > > I only see a superficial analogy with `super()`, but perhaps it 
is

 > > because you did not give much details of you suggestion.
 >
 > No, it's because the analogy was not meant to be anything more 
than

 > superficial. Both are constructs of syntactic magic that aid
 > readability at
 > a high level but potentially obscure the details of execution (in
 > relatively unimportant ways) when examined at a low level.

 Since i understand that the "super() magic" is just evaluation in a
 predefined environment, it does not look so very magic.


It's the reason why this doesn't work:

superduper = super

class A:
def f(self):
return 42

class B(A):
def f(self):
return superduper().f()


 B().f()

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in f
RuntimeError: super(): __class__ cell not found

But this does:

class C(A):
def f(self):
return superduper().f()
not super


 C().f()

42

I don't know, seems magical to me.

 Moreover, without this "magic", `super()` would have just produced 
an
 error.  So this magic did not change behaviour of something that 
worked

 before, it made "magically" work something that did not work before
 (but i am still not excited about it).


I'm curious how you feel about this example then (from the CPython 
3.7.2
REPL; results from different Python implementations or from scripts 
that

comprise a single compilation unit may vary)?


 372 is 372

True

 b = 372; b is 372

True

 b = 372
 b is 372

False


 > Maybe it was from my talk of implementing this by replacing the
 > assignment
 > with an equivalent def statement in the AST. Bear in mind that 
the def
 > statement is already just a particular kind of assignment: it 
creates

 > a
 > function and assigns it to a name. The only difference between the
 > original
 > assignment and the def statement that replaces it is in the 
__name__
 > attribute of the function object that gets created. The proposal 
just

 > makes
 > the direct lambda assignment and the def "assignment" to be fully
 > equivalent.

 `def` is not an assignment, it is more than that.


def is an assignment where the target is constrained to a single 
variable

and the expression is constrained to a newly created function object
(optionally "decorated" first with one or more composed function 
calls).

The only ways in which:

@decorate
def foo(blah):
return stuff

is more than:

foo = decorate(lambda blah: stuff)

are: 1) the former syntactically allows statements inside the function
body, not just expressions; 2) the former syntactically allows 
annotations
on the function; and 3) the former syntactically sets a function name 
and
the latter doesn't. In other words, all of the differences ultimately 
boil

down to syntax.


Sorry, i do not feel like continuing this discussion for much longer, 
or we need to concentrate on some specific statement on which we 
disagree.


I clarified what i meant by an assignment, and i believe it to be a 
usual meaning.


 1. `def` is not an assignment, there is no left-hand side or 
right-hand side. I was talking about the normal assignment by which 
anyone can bind any value to any variable.


 2. If i execute an assignment statement

foo = ...

and instead of evaluating the right-hand side and assigning the 
value to "foo" variable Python does something else, i consider the 
assignment operation ( = ) broken, as it does not do 
assignment (and only assignment). I've said more on this in previous 
messages.


 3. About the examples with `372 is 372`, Python gives no garanties 
about the id's of numerical objects, and about id's of many other types 
of immutable objects. The user is not supposed to rely on their 
equality or inequality.


Anytime Python's interpreter encounter two immutable objects that 
it finds identical, it is free to allocate a single object for both, 
this does not change the guaranteed semantics of the program.


The '__name__' attribute of an object, as well as most (or all) 
other attributes, is a part of object's value/contents, no analogies 
with the id's.


I am sorry, but except maybe for one or two more very specific 
questions, I am probably not going to continue.


Alexey.



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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov  wrote:
> I clarified what i meant by an assignment, and i believe it to be a
> usual meaning.
>
>   1. `def` is not an assignment, there is no left-hand side or
> right-hand side. I was talking about the normal assignment by which
> anyone can bind any value to any variable.

Actually, a 'def' statement DOES perform assignment. It does a bit
more than that, but it definitely is assignment. You can easily check
the CPython disassembly:

>>> import dis
>>> def f():
... def g(x): return x * 3 + 1
...
>>> dis.dis(f)
  2   0 LOAD_CONST   1 (", line 2>)
  2 LOAD_CONST   2 ('f..g')
  4 MAKE_FUNCTION0
  6 STORE_FAST   0 (g)
  8 LOAD_CONST   0 (None)
 10 RETURN_VALUE

[disassembly of g() omitted as it's irrelevant]

At run time, the statement "def g(x): ..." means "grab this code
object and this name, make a function, *and assign it to the name g*".

Your other points, I agree on.

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

Re: DeprecationWarning in Python 3.6 and 3.7

[Rhodri James]

On 02/04/2019 16:52, אורי wrote:

On Tue, Apr 2, 2019 at 6:33 PM Terry Reedy  wrote:


On 4/2/2019 6:29 AM, אורי wrote:

Hi,

Please look at this issue:
DeprecationWarning in Python 3.6 and 3.7


I tried to upgrade to the latest virtualenv (virtualenv==16.4.3) in the
tests but the tests still fail in Python 3.6 and 3.7 with
the DeprecationWarning:

Which is?


I don't understand your question.


What is the DeprecationWarning?  You gave us a couple of links, which no 
one with any sense is going to click on without checking they are valid, 
and frankly I can't be bothered.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

fs package question - cp -p semantics when copying files?

[Skip Montanaro]

I posed this yesterday on the PyFilesystem discussion Google Group but
it's so far not even garnered a single view, so perhaps that group is
defunct. I turn to the knowledgeable folks here:

I am copying files from one filesystem instance to another. I see no
(easy) way to tell fs.copy.copy_fs to preserve file permissions when
copying files (the equivalent of the cp(1)'s -p flag). So, accessed,
created, modified times, as well as permissions. It seems I need to
craft a dictionary with only marginally documented structure, which I
can then pass to the destination filesystem's setinfo method,
something like this:

dst_fs.setinfo(dst_path, )

I suspect I will figure this out (painfully), but if someone has some
hints, they'd be appreciated.

Thanks,

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

Clicking a specific item within a drop down list

[rlew2008]

What code would allow me to automatically select and click the "Quarterly" 
value from the drop-down box labeled "Statement Type" on the web page below.

I'm new to Python and have been struggling with this one. Any help is immensely 
appreciated. Thanks!

http://financials.morningstar.com/balance-sheet/bs.html?t=XNYS:MMM®ion=usa&culture=en-US&platform=sal
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clicking a specific item within a drop down list

[DL Neil]

On 3/04/19 7:53 AM, rlew2...@gmail.com wrote:

What code would allow me to automatically select and click the "Quarterly" value from the 
drop-down box labeled "Statement Type" on the web page below.

I'm new to Python and have been struggling with this one. Any help is immensely 
appreciated. Thanks!


Welcome!
People here offer great assistance.

To help you, please advise:
Which Python book, course, or tutorial have you been following?
Is this task course-work or for some other purpose?
Which GUI library are you using?
What code do you have so far?
What error message and/or screen behavior results?

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[Karsten Hilbert]

On Tue, Apr 02, 2019 at 01:29:08PM +0300, אורי wrote:

> DeprecationWarning in Python 3.6 and 3.7
> 
>
> I tried to upgrade to the latest virtualenv (virtualenv==16.4.3) in the
> tests but the tests still fail in Python 3.6 and 3.7 with
> the DeprecationWarning:
>
> (with Pillow==5.4.1):
> https://travis-ci.org/speedy-net/speedy-net/builds/514284524
>
> (with Pillow==6.0.0):
> https://travis-ci.org/speedy-net/speedy-net/builds/514595887
>
> What is the problem?

Missing information.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[Inada Naoki]

The DeprecationWarning is raised for virtualenv's distutils.
It is fixed already.  Use latest virtualenv.

Links:
https://github.com/pypa/virtualenv/pull/1289
https://virtualenv.pypa.io/en/latest/changes/#v16-4-0-2019-02-09
-- 
Inada Naoki  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clicking a specific item within a drop down list

[rlew2008]

Hi dn,

Thank you kindly for your warm greeting.  Please forgive my lack of forum 
decorum, I just started Python 2 days ago out of necessity, so I'm still quite 
unknowledgable about a lot of things.  

I'm working on a person project.  So far, my only resources to date have been 
forums based off of Google searches, and a YouTube video: 
https://www.youtube.com/watch?v=rfscVS0vtbw

This is the code that I have so far:

from selenium import webdriver
driver = webdriver.Chrome()
driver.get("http://financials.morningstar.com/balance-sheet/bs.html?t=XNAS:AAPL®ion=usa&culture=en-US";)
import time
time.sleep(2)
driver.find_element_by_id("menu_A")
driver.find_element_by_link_text("Quarterly")

When I run it, I get this error code:

selenium.common.exceptions.NoSuchElementException: Message: no such element: 
Unable to locate element: {"method":"link text","selector":"Quarterly"}

I've exhausted all of the forum posts I can find on this topic, but I've still 
been unable to solve it.  Any suggestions on how to solve it are eagerly 
welcomed.

Cheers,
Richard



On Tuesday, April 2, 2019 at 1:22:35 PM UTC-7, DL Neil wrote:
> On 3/04/19 7:53 AM, rlew2...@gmail.com wrote:
> > What code would allow me to automatically select and click the "Quarterly" 
> > value from the drop-down box labeled "Statement Type" on the web page below.
> > 
> > I'm new to Python and have been struggling with this one. Any help is 
> > immensely appreciated. Thanks!
> 
> Welcome!
> People here offer great assistance.
> 
> To help you, please advise:
> Which Python book, course, or tutorial have you been following?
> Is this task course-work or for some other purpose?
> Which GUI library are you using?
> What code do you have so far?
> What error message and/or screen behavior results?
> 
> -- 
> Regards =dn

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

Re: Clicking a specific item within a drop down list

[DL Neil]

Richard,
(this is a Python list, and whilst the question is quite proper - your 
are using Python after all, the answer delves into Selenium and then 
dives into HTML and finally disappears into 'the dark side' of JavaScript!)



On 3/04/19 2:02 PM, rlew2...@gmail.com wrote:

Hi dn,
Thank you kindly for your warm greeting.  Please forgive my lack of forum 
decorum, I just started Python 2 days ago out of necessity, so I'm still quite 
unknowledgable about a lot of things.
I'm working on a person project.  So far, my only resources to date have been 
forums based off of Google searches, and a YouTube video: 
https://www.youtube.com/watch?v=rfscVS0vtbw
This is the code that I have so far:
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("http://financials.morningstar.com/balance-sheet/bs.html?t=XNAS:AAPL®ion=usa&culture=en-US";)
import time
time.sleep(2)
driver.find_element_by_id("menu_A")
driver.("Quarterly")
When I run it, I get this error code:
selenium.common.exceptions.NoSuchElementException: Message: no such element: Unable to locate element: 
{"method":"link text","selector":"Quarterly"}
I've exhausted all of the forum posts I can find on this topic, but I've still 
been unable to solve it.  Any suggestions on how to solve it are eagerly 
welcomed.



Python is being helpful. Stop and read the error message: "Unable to 
locate element". What can you learn from the components of that msg?


The error was found by Selenium.
Did you look within their documentation?
Sadly, a quick web-search link to their web site basically repeats the 
err.msg. Big deal!


The subject Selenium is examining is a web page.
In this case the word "element" is not part of Python, nor is it part of 
Selenium (per-se), but is an HTML term.
Have you opened that page in your web-browser? (bring it up again, if 
necessary)


Usually I would suggest using the web-browser to look at HTML elements, 
indeed Firefox's (right-mouse-click) Context Menu offers an "Inspect 
Element" function, or use of the "Developer Tools" (F12). NB 
Chromium/Chrome and presumably the Apple and MSFT products offer similarly.


In this case, may I recommend (first) using the web-browser's "View 
Source" facility (Context or Tool menus) to inspect the HTML code of 
this web page.

What happens when you try to find "Quarterly" on the page?

Yes, it is found, but that's not in the place you expect ("menu_A")!

Return to the web page and now try the "Inspect Element" function.
Ahah, the "quarterly" link content *is* there.
What is going on?

Return to the page source, scroll through to (manually) find the Balance 
Sheet. It's not there either!

Yet, on the web page you can see it with your own eyes!!!???

What is there, around line 259 of the HTML, is a call to a JavaScript 
script.

What did I say about "going over to the dark side"?

You ask Selenium to load a web page. In turn, the browser/driver 
discovers that the web-page/HTML loads other items/files, eg graphics, 
CSS files, and JavaScript code files.


That's where the problem (seems to) lies - and it also explains the 
difference between Firefox's "View Source" facility and the "Developer 
Tools". Selenium works fast. Accordingly, as soon as the HTML page is 
available, it finds "menu_A" and thence attempts to find the "Quarterly" 
link. Unfortunately, the JavaScript needs to be loaded (from a separate 
file on the web server) and executed. You have a "race condition". The 
solution (hopefully - I have not tested it) is to add a delay between 
the page-load and the search-analysis (and possibly again, to allow the 
quarterly analysis to load before commencing the next step...


WebRefs:
https://stackoverflow.com/questions/6936149/how-to-use-find-element-by-link-text-properly-to-not-raise-nosuchelementexcept
https://en.wikipedia.org/wiki/Race_condition


Let us know how you get on...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: fs package question - cp -p semantics when copying files?

[DL Neil]

Skip,

On 3/04/19 8:06 AM, Skip Montanaro wrote:

I posed this yesterday on the PyFilesystem discussion Google Group but
it's so far not even garnered a single view, so perhaps that group is
defunct. I turn to the knowledgeable folks here:

I am copying files from one filesystem instance to another. I see no
(easy) way to tell fs.copy.copy_fs to preserve file permissions when
copying files (the equivalent of the cp(1)'s -p flag). So, accessed,
created, modified times, as well as permissions. It seems I need to
craft a dictionary with only marginally documented structure, which I
can then pass to the destination filesystem's setinfo method,
something like this:

 dst_fs.setinfo(dst_path, )

I suspect I will figure this out (painfully), but if someone has some
hints, they'd be appreciated.


Is there an (unstated) reason why you're using Python and not a system 
tool such as rsync?


--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[אורי]

אורי
u...@speedy.net


On Wed, Apr 3, 2019 at 2:50 AM Inada Naoki  wrote:

> The DeprecationWarning is raised for virtualenv's distutils.
> It is fixed already.  Use latest virtualenv.
>

That's what I wrote. I tried to upgrade to the latest virtualenv
(virtualenv==16.4.3) in the tests but the tests still fail in Python 3.6
and 3.7 with the DeprecationWarning. You can see the "pip freeze" before
the tests start.

(with Pillow==5.4.1):
https://travis-ci.org/speedy-net/speedy-net/builds/514284524

(with Pillow==6.0.0):
https://travis-ci.org/speedy-net/speedy-net/builds/514595887



>
> Links:
> https://github.com/pypa/virtualenv/pull/1289
> https://virtualenv.pypa.io/en/latest/changes/#v16-4-0-2019-02-09
> --
> Inada Naoki  
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning in Python 3.6 and 3.7

[Inada Naoki]

See this log.

https://travis-ci.org/speedy-net/speedy-net/jobs/514595889

1. In line 172, you *enabled* virtualenv, created by Travis-CI with
old virtualenv library.
2. In the legacy virtualenv, you installed latest virtualenv.

You need to enable virtualenv, *created by* latest virtualenv.
Install latest virtualenv in virtualenv *created by* old virtualenv is
not enough.

‪On Wed, Apr 3, 2019 at 11:35 AM ‫אורי‬‎  wrote:‬
>
>
> אורי
> u...@speedy.net
>
>
> On Wed, Apr 3, 2019 at 2:50 AM Inada Naoki  wrote:
>>
>> The DeprecationWarning is raised for virtualenv's distutils.
>> It is fixed already.  Use latest virtualenv.
>
>
> That's what I wrote. I tried to upgrade to the latest virtualenv 
> (virtualenv==16.4.3) in the tests but the tests still fail in Python 3.6 and 
> 3.7 with the DeprecationWarning. You can see the "pip freeze" before the 
> tests start.
>
> (with Pillow==5.4.1):
> https://travis-ci.org/speedy-net/speedy-net/builds/514284524
>
> (with Pillow==6.0.0):
> https://travis-ci.org/speedy-net/speedy-net/builds/514595887
>
>
>>
>>
>> Links:
>> https://github.com/pypa/virtualenv/pull/1289
>> https://virtualenv.pypa.io/en/latest/changes/#v16-4-0-2019-02-09
>> --
>> Inada Naoki  



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

Re: DeprecationWarning in Python 3.6 and 3.7

[אורי]

אורי
u...@speedy.net


On Wed, Apr 3, 2019 at 6:12 AM Inada Naoki  wrote:

> See this log.
>
> https://travis-ci.org/speedy-net/speedy-net/jobs/514595889
>
> 1. In line 172, you *enabled* virtualenv, created by Travis-CI with
> old virtualenv library.
> 2. In the legacy virtualenv, you installed latest virtualenv.
>
> You need to enable virtualenv, *created by* latest virtualenv.
> Install latest virtualenv in virtualenv *created by* old virtualenv is
> not enough.
>

Thank you, I understand now. I'm sorry about the misunderstanding.
The virtualenv enabled in line 172 is from Travis. Do you know if it's
possible to change it's version? It's the default virtualenv of these
versions of Python (3.6 & 3.7) and I don't know how to change it. Should I
wait until Travis will upgrade their default virtualenv versions? Or can I
upgrade it manually?

The first line of code from my script in the log above is line 177 (`cp
env.ini.tests env.ini`), which comes from
https://github.com/speedy-net/speedy-net/blob/uri_run_tests_with_deprecation_warnings_2019-04-02_a/.travis.yml
line
17.

I also asked this question on Stack Overflow:
https://stackoverflow.com/questions/55486248/deprecationwarning-in-python-3-6-and-3-7-with-pillow



>
> ‪On Wed, Apr 3, 2019 at 11:35 AM ‫אורי‬‎  wrote:‬
> >
> >
> > אורי
> > u...@speedy.net
> >
> >
> > On Wed, Apr 3, 2019 at 2:50 AM Inada Naoki 
> wrote:
> >>
> >> The DeprecationWarning is raised for virtualenv's distutils.
> >> It is fixed already.  Use latest virtualenv.
> >
> >
> > That's what I wrote. I tried to upgrade to the latest virtualenv
> (virtualenv==16.4.3) in the tests but the tests still fail in Python 3.6
> and 3.7 with the DeprecationWarning. You can see the "pip freeze" before
> the tests start.
> >
> > (with Pillow==5.4.1):
> > https://travis-ci.org/speedy-net/speedy-net/builds/514284524
> >
> > (with Pillow==6.0.0):
> > https://travis-ci.org/speedy-net/speedy-net/builds/514595887
> >
> >
> >>
> >>
> >> Links:
> >> https://github.com/pypa/virtualenv/pull/1289
> >> https://virtualenv.pypa.io/en/latest/changes/#v16-4-0-2019-02-09
> >> --
> >> Inada Naoki  
>
>
>
> --
> Inada Naoki  
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Logging module and datetime - oil & water for some reason?

[DL Neil]

Skip,


On 2/04/19 9:54 AM, Skip Montanaro wrote:

I assiduously avoided using Python's logging package for about the
first dozen years of its existence. I eventually gave in and started


I'm glad you're stepping-up!

I'm never sure whether to be amazed or dismayed by the huge number of 
folk expressing/hiding this sort of 'fear'.

(not that I'm insulting you - you might be bigger than I!)

Have spent some time over the last two days, contemplating an 'upgrade' 
from ordinary files to a RotatingFileHandler, so, with the manual fresh 
in my mind, you're in-luck!

(maybe)



using it relatively recently in the guise of a thin wrapper provided
by a colleague at work. Today I had occasion to tweak the timestamp
format only to discover that logging still uses time.localtime or
time.gmtime as its underlying source of time fields, so subsecond
timestamps are hacked in, with no straightforward way to log both
milliseconds and the timezone in normal order. I have need for both,
as I work for a company with offices in multiple timezones, and
sometimes need subsecond time resolution for quick-n-dirty analysis.


Prepare for that "thin wrapper" (and most of the provided 'convenience 
functions') to disappear in your rear-view mirror!




I stole a custom formatter class from a StackOverflow thread and am
now back in business (milliseconds *and* timezones, yay!). Still,
peeking at the 2.7 documentation, I see that both the logging package
and the datetime module were added to the standard library in Python
2.3 (2003). Why is logging still relying on the suboptimal
time.{localtime,gmtime} API? Surely, if there was no
backwards-compatible way to introduce datetime into the system, a
small breaking change could have been made for Python 3000 and
probably affected very few users.


The formatTime method was added to the Formatter class in Python 3.3. 
(see docs, if v3.3 is an option available to you)


Otherwise, your idea of implementing a sub-class was likely the best 
approach.


Another introduction (v3.2) has been LoggerAdapter objects. I've not 
used them(!) but wondered if they might have purpose in such situations?


In multi-national situations, my recommendation has long been to 
standardise all times (incl logging) as UTC.


I'm not sure if it was available as far back as Py2, but there is a 
SysLogHandler() which enables disparate and dispersed applications to 
log to a central 'logging server'. (although I wonder if the formatters 
would still be using local time (or whatever), or if the 'time' relates 
to that central server)


Am unable to comment on, or answer, the last question.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list