[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-08-30 Thread Francis Herne
https://bugs.kde.org/show_bug.cgi?id=378083

Francis Herne  changed:

   What|Removed |Added

 CC||antonis+kdebugs@metadosis.g
   ||r

--- Comment #6 from Francis Herne  ---
*** Bug 323796 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-07-27 Thread Francis Herne
https://bugs.kde.org/show_bug.cgi?id=378083

Francis Herne  changed:

   What|Removed |Added

  Latest Commit||https://commits.kde.org/kde
   ||v-python/1a7d3c139ab7b4ab43
   ||9d757a95a5d7d83575f801
   Version Fixed In||5.2.0
 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Francis Herne  ---
Git commit 1a7d3c139ab7b4ab439d757a95a5d7d83575f801 by Francis Herne.
Committed on 27/07/2017 at 23:21.
Pushed by flherne into branch 'master'.

Rewrite declarationForName()

This causes the correct declaration to be found in some unusual cases
 that previously failed.

Only names declared before a function definition, or at module scope,
 were found in its body. Names may be declared later (but before the
 function is called); these were not found.
FIXED-IN: 5.2.0

Class attributes from any enclosing class definition were found in
 default arguments, not only those from a method's parent class.

Class or instance attributes were, correctly, not directly visible
 inside a method body (only with `self.` or similar), but hid
 declarations of the same name in outer contexts that should be found.

M  +35   -33   duchain/helpers.cpp
M  +60   -5duchain/tests/pyduchaintest.cpp

https://commits.kde.org/kdev-python/1a7d3c139ab7b4ab439d757a95a5d7d83575f801

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-04-03 Thread Diego Garcia
https://bugs.kde.org/show_bug.cgi?id=378083

--- Comment #4 from Diego Garcia  ---
Heh never thought about putting functions in the middle.
Yes, that works. It could be a good workaround for new code.
It'd be great if it could be fixed though

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-04-03 Thread Francis Herne
https://bugs.kde.org/show_bug.cgi?id=378083

Francis Herne  changed:

   What|Removed |Added

 CC||m...@flherne.uk
 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1
   Assignee|m...@svenbrauch.de  |m...@flherne.uk

--- Comment #3 from Francis Herne  ---
In your example, this should work?
---
def test_closures():
this = 'that'

def test_inner():
print(this)

return test_inner
# or test_inner()
---

But I think it would be possible to create a case where that isn't an option,
and the original examples are valid code anyway.

Shouldn't be too hard to fix, we need to continue beyond the current line when
searching in parents of a function context.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-03-26 Thread Diego Garcia
https://bugs.kde.org/show_bug.cgi?id=378083

--- Comment #2 from Diego Garcia  ---
The problem is that when you want to call the inner function or return it, it
will also get flagged as an error. And it would be correct since this code
fails.

---
def test_closures():
this = 'that'

return test_inner
# or test_inner()

def test_inner():
print(this)
---

The first snippet is the (AFAIK) only way to do closures or nested functions in
Python.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdev-python] [Bug 378083] Variables from parent function in closures are considered undefined

2017-03-25 Thread Sven Brauch
https://bugs.kde.org/show_bug.cgi?id=378083

--- Comment #1 from Sven Brauch  ---
Yeah, this is a difficult case. In my opinion the current behaviour is ok: you
cannot sensibly call the function before defining the variable, so you can just
as well re-order your code to define the variable first ...

-- 
You are receiving this mail because:
You are watching all bug changes.