[Tutor] Pytest help

[Sahil Chauhan]

Hi,

I am trying to use py.test for writing some selenium webdriver tests. I
wrote my first test and
pytest is deselecting that test even though I didn't mark any test.

How can I resolve this issue?  Is there some default setting used by
py.test,


(qa)MacBook-Air:$  py.test tests/test_login.py
===
test session starts
===
platform darwin -- Python 2.7.6 -- pytest-2.2.4
collected 1 items

===
*1 tests deselected by "-m 'nondestructive'" *
===
==
1 deselected in 0.01 seconds ==




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

Re: [Tutor] Pytest help

[Oscar Benjamin]

On Tue, 7 Jul 2015 at 09:51 Sahil Chauhan  wrote:

> Hi,
>
> I am trying to use py.test for writing some selenium webdriver tests. I
> wrote my first test and
> pytest is deselecting that test even though I didn't mark any test.
>
> How can I resolve this issue?  Is there some default setting used by
> py.test,
>
>
I don't know as that's never happened to me and you haven't shown any code
for me to check. Try breaking your problem down to a small example
module+test that still exhibits the same behaviour. You may find that you
solve the problem in the process. If not then post the small example code
here so that someone else can see what the problem is.

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

Re: [Tutor] Pytest help

[Mark Lawrence]

On 07/07/2015 03:16, Sahil Chauhan wrote:

Hi,

I am trying to use py.test for writing some selenium webdriver tests. I
wrote my first test and
pytest is deselecting that test even though I didn't mark any test.

How can I resolve this issue?  Is there some default setting used by
py.test,

(qa)MacBook-Air:$  py.test tests/test_login.py
===
test session starts
===
platform darwin -- Python 2.7.6 -- pytest-2.2.4
collected 1 items

===
*1 tests deselected by "-m 'nondestructive'" *
===
==
1 deselected in 0.01 seconds ==

Thanks in advance!
Sahil



Hopefully this helps https://pytest.org/latest/example/markers.html 
based on your reference to "selenium webdriver tests" and its reference 
to "@pytest.mark.webtest".


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

Mark Lawrence

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

Re: [Tutor] Pytest help

[Alan Gauld]

On 07/07/15 03:16, Sahil Chauhan wrote:

Hi,

I am trying to use py.test for writing some selenium webdriver tests. I
wrote my first test and
pytest is deselecting that test even though I didn't mark any test.

How can I resolve this issue?  Is there some default setting used by
py.test,



The best place to ask for help on any 3rd party package is on the 
package's own support forum/list. Py.test has several options:


https://pytest.org/latest/contact.html


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


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

Re: [Tutor] Pytest help :p:

[Thomas C. Hicks]

On 07/07/2015 06:58 PM, Alan Gauld wrote:


The best place to ask for help on any 3rd party package is on the 
package's own support forum/list. Py.test has several options:


https://pytest.org/latest/contact.html
The Testing In Python 
 mailing list is 
outstanding, civil, knowledgable people really wanting to help.


==
Thomas C. Hicks, MD, MPH
Training Manager, Gansu Gateway
Lanzhou, Gansu, PR China
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Variable reference

[Peter Otten]

Alan Gauld wrote:

> On 07/07/15 01:18, Danny Yoo wrote:
>> I'd also add that the 'del' statement has near-zero utility.
>>
>> 'del' is a language blemish.  It should not be used by beginners,
>> because it asks them to try to manually manage the lifetime of their
>> variable names.  That's an unreasonable and ridiculous burden.
>> Functions have local variables for a reason.
> 
> I don't know that I'd go that far. There are valid uses for
> it in deleting things from dictionaries and the like.

For dicts and lists a method would work as well. Even now you can write

items.pop(index) # instead of del items[index]
lookup.pop(key) # del lookup[key]

If you find the name pop() random or hard to discover a delete() method 
could be added.

globals().pop("name") # instead of del name in the global namespace
delattr(obj, "name") # del obj.name

For the above the replacement is less elegant, but I don't think it matters 
for a rarely used feature. So for everything but local and nonlocal names 
del is syntactic sugar at best.

> But I agree its not needed very often and can lead to
> users over-managing their data.
 


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

Re: [Tutor] Variable reference

[Steven D'Aprano]

On Tue, Jul 07, 2015 at 04:08:30PM +0200, Peter Otten wrote:

> For dicts and lists a method would work as well. Even now you can write
> 
> items.pop(index) # instead of del items[index]
> lookup.pop(key) # del lookup[key]
> 
> If you find the name pop() random or hard to discover a delete() method 
> could be added.
> 
> globals().pop("name") # instead of del name in the global namespace
> delattr(obj, "name") # del obj.name
> 
> For the above the replacement is less elegant, but I don't think it matters 
> for a rarely used feature. So for everything but local and nonlocal names 
> del is syntactic sugar at best.

Not so. The point of del being a statement is that it should be 
considered an operation on the *reference*, not the *value* of the 
reference. So:

x = 23
delete(x)  # if it existed, it would see the value 23
del x  # operates on the reference "x", not 23

We can work around this by quoting the variable name:

delete("x")  # this could work

but that is not an elegant design. It's a work-around for the fact that 
Python doesn't have dedicated syntax to say "operate on the reference 
foo" rather than the value of foo.

In Python, I think there are only two operations on references 
themselves: binding, and unbinding. For some purposes, we can consider 
unbinding just a special case of binding. (For example, adding a `del 
spam` line to a function makes spam a local, just as assigning to it 
would.) All binding operations are firstly statements, not function 
calls:

x = 23  # not assign("x", 23)
import spam
for eggs in sequence
with expr as cheese
except SomeError as foo


and del is no exception. For some of these, there are functional 
versions: setattr, delattr come to mind, but I don't think there are 
many others. dict.pop and similiar are not conceptually the same, as 
they don't operate on references, they operate on keys, indexes, names 
as strings, etc.

I acknowledge that there is some overlap between the two, and one can 
replace the other (at least sometimes), but conceptually they operate in 
different spheres.



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

Re: [Tutor] Variable reference

[Peter Otten]

Steven D'Aprano wrote:

> On Tue, Jul 07, 2015 at 04:08:30PM +0200, Peter Otten wrote:
> 
>> For dicts and lists a method would work as well. Even now you can write
>> 
>> items.pop(index) # instead of del items[index]
>> lookup.pop(key) # del lookup[key]
>> 
>> If you find the name pop() random or hard to discover a delete() method
>> could be added.
>> 
>> globals().pop("name") # instead of del name in the global namespace
>> delattr(obj, "name") # del obj.name
>> 
>> For the above the replacement is less elegant, but I don't think it
>> matters for a rarely used feature. So for everything but local and
>> nonlocal names del is syntactic sugar at best.
> 
> Not so. The point of del being a statement is that it should be
> considered an operation on the *reference*, not the *value* of the
> reference. So:
> 
> x = 23
> delete(x)  # if it existed, it would see the value 23
> del x  # operates on the reference "x", not 23

Read again. I said that

del x

in the global namespace can be emulated with

globals().pop("x")

and that there is no equivalent to

del x

if x is a local/nonlocal name.

> 
> We can work around this by quoting the variable name:
> 
> delete("x")  # this could work
> 
> but that is not an elegant design. 

I agree that if you think that explicitly unbinding a name is a useful 
feature of the language a statement is the way to go. For me it's a feature 
I hardly ever use and that I hardly ever find compelling in other people's 
code. I'd happily resort to

x = None

should the need arise to dereference a specific variable.


> It's a work-around for the fact that
> Python doesn't have dedicated syntax to say "operate on the reference
> foo" rather than the value of foo.

I think Danny's point was that you should not micromanage name bindings at 
all. Then Alan added that del is useful for dicts etc. on which I replied 
that a method would be sufficient for that.

> In Python, I think there are only two operations on references
> themselves: binding, and unbinding. For some purposes, we can consider
> unbinding just a special case of binding. (For example, adding a `del
> spam` line to a function makes spam a local, just as assigning to it
> would.) All binding operations are firstly statements, not function
> calls:
> 
> x = 23  # not assign("x", 23)
> import spam
> for eggs in sequence
> with expr as cheese
> except SomeError as foo
> 
> 
> and del is no exception. For some of these, there are functional
> versions: setattr, delattr come to mind, but I don't think there are
> many others. dict.pop and similiar are not conceptually the same, as
> they don't operate on references, they operate on keys, indexes, names
> as strings, etc.
> 
> I acknowledge that there is some overlap between the two, and one can
> replace the other (at least sometimes), but conceptually they operate in
> different spheres.

I'd put that the other way round: allowing both

del a["x"] # invokes a method on `a`

and

del x # manipulates a namespace

glosses over the "conceptual difference"; if a clean approach were the goal 
only the latter should be allowed.

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

Re: [Tutor] Variable reference

[Danny Yoo]

>> It's a work-around for the fact that
>> Python doesn't have dedicated syntax to say "operate on the reference
>> foo" rather than the value of foo.
>
> I think Danny's point was that you should not micromanage name bindings at
> all. Then Alan added that del is useful for dicts etc. on which I replied
> that a method would be sufficient for that.

Yes.  Apologies for not being clear.

I was thinking of the two recent uses of 'del' showing up on the
mailing list in the past week or so.  Both of the uses, from different
authors, were trying to manually manage name bindings.  It made the
code harder to understand. In both cases, both uses of 'del' were
ineffective.

When I'm reading code, I want to know statically what my variables
are.  By statically, I mean that I should be able to tell, just be
reading the code, what the code means, without running it.  "What
variables are accessible?" is one of the most basic questions I ask
myself when I'm reading code.

But if we use 'del' on name bindings, that makes the set of accessible
variables a dynamic property that, in the most general case, requires
us to run the code to figure it out.

When I'm trading a static property for a dynamic property, I want to
get a useful amount of power for that tradeoff, because it's costly.
In my opinion, 'del' on a name binding is just not useful enough to be
worth that conceptual cost.  'del' to remove attributes or dictionary
key/value pairs is a different matter.  I want to constrain my
objections to 'del' specifically to its use on name bindings.

That all being said: wow.  I'm getting a heck of a lot more
curmudgeon-y these days.  :P
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Variable reference

[Steven D'Aprano]

On Tue, Jul 07, 2015 at 06:50:25PM +0200, Peter Otten wrote:
[...]

> > Not so. The point of del being a statement is that it should be
> > considered an operation on the *reference*, not the *value* of the
> > reference. So:
> > 
> > x = 23
> > delete(x)  # if it existed, it would see the value 23
> > del x  # operates on the reference "x", not 23
> 
> Read again. I said that
> 
> del x
> 
> in the global namespace can be emulated with
> 
> globals().pop("x")
> 
> and that there is no equivalent to
> 
> del x
> 
> if x is a local/nonlocal name.

Yes, I read all that. There *could* (at least in theory) be an 
equivalent to `del x` using a function, which I called `delete("x")`, 
that applied to locals/nonlocals as well as globals. It would still not 
be *close* equivalent to del, because they operate in different spheres, 
semantically.

Using pop() is not quite right, because it doesn't just remove the 
key:value pair, it *returns the value*. So that's a another difference 
between popping a key from the globals, and del:

del x: 
- operates on the variable x, not the value of x
- unbinds that variable
- has no return result (is a statement, not an expression

globals().pop("x"):
- operates on a value, the string "x", not a variable
- conceptually, not an unbinding operation at all
- returns the value bound to the variable x

This makes a practical difference at the interactive interpreter: 
popping as two side effects, only one of which is intended:

py> a, b = 1, 2
py> del a
py> globals().pop("b")
2


It's unlikely to change, since the current semantics of globals() is 
documented as a language feature, but in principle at least a Python 
implementation might optimize the language by making globals() more like 
locals(), i.e. calling globals() returns a *copy* of the global 
namespace, not the namespace itself.

As I said, this is unlikely to change without a period of deprecation, 
but still, del is *intended* to unbind variables, pop is not. The fact 
that globals().pop also unbinds them is an accident of the way manages 
globals.

For all these reasons, if I saw 

globals().pop("x")

in code I was reviewing, I would change it to `del x` without 
hesitation. Not withstanding the fact that we *can* replace del with pop 
as above, we shouldn't.


[...]
> I agree that if you think that explicitly unbinding a name is a useful 
> feature of the language a statement is the way to go. For me it's a feature 
> I hardly ever use and that I hardly ever find compelling in other people's 
> code.

I completely agree that del is rarely useful! But *rare* is not *never*.

There are two compelling cases for using del on names: explicitly 
managing the names in a namespace (i.e. to avoid "namespace pollution") 
and avoiding long-lived global references to objects which you no 
longer need.

I agree that using del on a local variable is probably unnecessary 
micro-management. I can't think of any scenario where you would want to 
manually del a local variable. If you did, that's possibly a sign that 
your function is too big.

When writing a script or application, name management is not a big deal. 
But in a library, temporary variables are pollution. They make it harder 
for the users of your library to tell what's part of the API and what 
isn't, and they make "from module import *" less useful. So if I have a 
temporary global variable, I may want to get rid of it once I'm finished 
with it. Here's a snippet from a library module I have, designed to be 
used with * imports:

tmp = set(C0.keys()) & set(C1.keys())
assert not tmp, 'duplicate control code acronyms: %s' % tmp
# Special check for SCG abbreviated acronym.
assert 'SGC' not in C0
assert 'SGC' not in C1
# Validate that the ^ and ESC codes are correct.
for C in (C0, C1):
for cc in C.values():
assert cc.code == _code(cc.ordinal), 'failed check: %s' % cc
del C, cc, tmp

Those three temporary variables, C, cc and tmp, would otherwise hang 
around forever, polluting the namespace and confusing my module's users. 
(My module's users, so far, is mostly me, but I'm easily confused.)


> I'd happily resort to
> 
> x = None
> 
> should the need arise to dereference a specific variable.

Ah, reading that makes me sad, because it looks like you are not getting 
the difference between a *variable* (a name in a namespace) and the
*value* of that variable.

`x = None` does not remove the variable from the namespace, it just 
binds it to None. So it is no substitute for the del statement.


> > It's a work-around for the fact that
> > Python doesn't have dedicated syntax to say "operate on the reference
> > foo" rather than the value of foo.
> 
> I think Danny's point was that you should not micromanage name bindings at 
> all. Then Alan added that del is useful for dicts etc. on which I replied 
> that a method would be sufficient for that.

Sure, Python *could* have used methods for deleting a key from a dict, 
or a