Re: [META] Are the list admins honouring Posting Prohibited demands?

[Gregory Ewing]

Steve D'Aprano wrote:

I notice that Lawrence D’Oliveiro has taken up labelling his posts with a
demand that his posts are not to be posted to the Python-List mailing list.


I don't think it's a demand. I gather that he has been banned from
posting on the Python mailing lists, and I think he's just saying
"I'm posting this here because I'm prohibited from posting on
python-list." That's what I took it to mean, anyway.

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

Re: [META] Are the list admins honouring Posting Prohibited demands?

[Tim Golden]

On 20/12/2017 05:52, Steve D'Aprano wrote:

This is possibly a question for the list admins...

I notice that Lawrence D’Oliveiro has taken up labelling his posts with a
demand that his posts are not to be posted to the Python-List mailing list.

I also see that his posts are not showing up on the mailing list archive. Is
this a coincidence or a direct consequence of his demand?


I'm not going to comment on the specific situation of Lawrence D'O 
posts. What I will say is:


* If someone were to ask specifically that we don't gateway their Usenet 
posts to the list, I can see no reason that we wouldn't honour that 
request. I'm not entirely sure about the reverse (list->Usenet) but 
AFAIK no-one's ever asked! I imagine it's possible.


* At different times we have decided to hold or discard posts made by 
certain people or servers or matching certain criteria, whether they're 
made via the list or gatewayed in from Usenet. The reasons are various 
but are usually obvious. Sometimes this is permanent; sometimes it's 
temporary.


* [I'm fairly sure] The Mailman software which runs the  list will 
honour no-archive headers. That is, it will gateway a given Usenet post 
to the list but will not include it in the archive.


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

Re: Python Templating Language

[Robin Becker]

On 17/12/2017 06:41, Abdur-Rahmaan Janhangeer wrote:

Hi all,

Can somebody point out to me some py-based template languages interpreters
resources?

Thank you !


https://bitbucket.org/rptlab/preppy
--
Robin Becker

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

Re: Python Templating Language

[Abdur-Rahmaan Janhangeer]

The sources of preppy are very nice! Thank you!

On Wed, Dec 20, 2017 at 1:25 PM, Robin Becker  wrote:

> On 17/12/2017 06:41, Abdur-Rahmaan Janhangeer wrote:
>
>> Hi all,
>>
>> Can somebody point out to me some py-based template languages interpreters
>> resources?
>>
>> Thank you !
>>
>> https://bitbucket.org/rptlab/preppy
> --
> Robin Becker
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Python: asyncio and Tkinter

[c.buhtz]

I am looking for an "elegant" and "official" way to use asyncio in
Tkinter applications. The goal is that the GUI is not freezing while
doing some download-tasks (over 100 files from different locations).

I am looking around on the web for solutions but couldn't find one.
Only some workarounds with unknown and possible sideffects.

I asked the same question on StackOverflow with a MWE


On my current state I wouuld say there is not an official solution for
this. asyncio and Tkinter are not build to work together without dirty
hacks.

Do you have other informations?

I think about combining asyncio with multithreading so the asyncio
event loop has it's own thread and is not blocking the GUI event loop.
Or using only multithreading.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Learning

[Marko Rauhamaa]

Larry Martell :

> On Mon, Dec 18, 2017 at 11:33 AM, Marko Rauhamaa  wrote:
>> However, one great way to stand out is a portfolio of GitHub
>> projects. Several people have gotten an offer largely based on those
>> (after they aced the technical interviews). For example, we just
>> hired someone who had written a game in sed. That doesn't make him an
>> "interesting person," nor do we look for game or sed developers. But
>> that silly exercise deeply resonated with our team. We expect to have
>> great synergy with him.
>
> I have been excluded from even getting an interview because I did not
> have a portfolio of GitHub projects. I think that is a bad filter. I
> work 60-70 hours a week for pay, and I have a family and personal
> interests.

Personal programming projects are not a requirement. They are just a
very effective advertising tool.

As for 60—70 hours a week... sounds horrible. My sympathies.


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

binary decision diagrams

[Wild, Marcel, Dr]

Hello everybody:
I really don't know anything about Python (I'm using Mathematica) but with the 
help of others learned that

g=expr2bdd(f)

makes the BDD (=binary decision diagram)  g of a Boolean function f.  But what 
is the easiest (fool-proof) way to print out a diagram of g ?

Regards, Marcel Wild

The integrity and confidentiality of this email is governed by these terms / 
Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende 
bepalings gere?l. http://www.sun.ac.za/emaildisclaimer
-- 
https://mail.python.org/mailman/listinfo/python-list

binary decision diagrams (BDD)

[Wild, Marcel, Dr]

Hello every body,
I'm new here and this is my first question.
I really don't know anything about Python (I use Mathematica) but with the help 
of others learned that

g=expr2bdd(f)

makes the BDD g of a Boolean function f.  But what is the easiest (fool-proof) 
way to print out the diagram of g (i.e. the usual binary tree) ?

The integrity and confidentiality of this email is governed by these terms / 
Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende 
bepalings gere?l. http://www.sun.ac.za/emaildisclaimer
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python: asyncio and Tkinter

[Chris Angelico]

On Wed, Dec 20, 2017 at 10:42 AM,   wrote:
> I am looking for an "elegant" and "official" way to use asyncio in
> Tkinter applications. The goal is that the GUI is not freezing while
> doing some download-tasks (over 100 files from different locations).
>
> ...
>
> I think about combining asyncio with multithreading so the asyncio
> event loop has it's own thread and is not blocking the GUI event loop.
> Or using only multithreading.

I would recommend threading. You can run your GUI event loop on one
thread, and your network I/O loop on another thread. Both threads
spend the bulk of their time blocked on I/O, and you've limited
yourself to a finite number of threads (as opposed to a pure threaded
approach with every download is run on a separate thread), so resource
consumption should be reasonable.

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

Re: binary decision diagrams

[Devin Jeanpierre]

On Mon, Dec 18, 2017 at 5:00 AM, Wild, Marcel, Dr 
 wrote:
> Hello everybody:
> I really don't know anything about Python (I'm using Mathematica) but with 
> the help of others learned that
>
> g=expr2bdd(f)
>
> makes the BDD (=binary decision diagram)  g of a Boolean function f.  But 
> what is the easiest (fool-proof) way to print out a diagram of g ?

Python doesn't come with support for (ro)bdds built-in. You're
probably thinking of this library, which includes visualization
instructions:

http://pyeda.readthedocs.io/en/latest/bdd.html

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

Re: [META] Are the list admins honouring Posting Prohibited demands?

[Rustom Mody]

FYI:

On Wednesday, December 20, 2017 at 11:22:52 AM UTC+5:30, Steve D'Aprano wrote:
> This is possibly a question for the list admins...
> 
> I notice that Lawrence D’Oliveiro has taken up labelling his posts with a
> demand that his posts are not to be posted to the Python-List mailing list.


Lawrence D’Oliveiro was banned on 30 Sept 2016
https://groups.google.com/d/msg/comp.lang.python/5dNmgPvXR7U/iRSEp4LrBQAJ


> 
> I also see that his posts are not showing up on the mailing list archive. Is
> this a coincidence or a direct consequence of his demand?


Ban is supposed to have ended as of June 23 2017 (end of thread). Evidently 
not??

https://groups.google.com/d/msg/comp.lang.python/yQEarGwOl6M/1e-mJg3FBQAJ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [META] Are the list admins honouring Posting Prohibited demands?

[Thomas Jollans]

On 2017-12-20 14:50, Rustom Mody wrote:
> FYI:
> 
> On Wednesday, December 20, 2017 at 11:22:52 AM UTC+5:30, Steve D'Aprano wrote:
>> This is possibly a question for the list admins...
>>
>> I notice that Lawrence D’Oliveiro has taken up labelling his posts with a
>> demand that his posts are not to be posted to the Python-List mailing list.
> 
> 
> Lawrence D’Oliveiro was banned on 30 Sept 2016
> https://groups.google.com/d/msg/comp.lang.python/5dNmgPvXR7U/iRSEp4LrBQAJ
> 
> 
>>
>> I also see that his posts are not showing up on the mailing list archive. Is
>> this a coincidence or a direct consequence of his demand?
> 
> 
> Ban is supposed to have ended as of June 23 2017 (end of thread). Evidently 
> not??

Who knows. Sometimes posts of his turn up, sometimes people reply to
posts of his that didn't turn up.

> 
> https://groups.google.com/d/msg/comp.lang.python/yQEarGwOl6M/1e-mJg3FBQAJ
> 


-- 
Thomas Jollans

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

Problems with imports on multiple threads, with embedded Python

[geoff . bache]

Hi all,

I have a multithreaded application using an embedded Python 3.6.4 (upgraded 
from 3.6.2 today in the hope that the problem was now solved: it doesn't seem 
to be). The standard library is in a zip file. So long as only one thread is 
running Python at a time it seems to work fine. But there seems to be a problem 
with the module importing when several Python threads are active.

I get a variety of errors indeterministically, usually indicating that some 
symbol hasn't been imported. This occurs both in my own code and in the 
standard library. The most frequent is probably this line:

dt = datetime.strptime(dtStr, fromFmt)

which produces

AttributeError: module '_strptime' has no attribute '_strptime_datetime' 

at random.

Does anyone have any insight into this problem?

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

Re: Tkinter,show pictures from the list of files in catalog-problem

[Ziggy]

On 2017-12-19, MRAB wrote:
>> 
> The function called by .after should return to the tkinter's event loop. 
> If you want to display a sequence of pictures, then the function should 
> call .after to make it call the function again.
>
> Here's a slightly reworked version:

Thanks. I like your solution, thanks to you I've learned about os.walk,
indeed makes everything easy.

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

Using the variable type annotation syntax as a placeholder in a nonlocal scope?

[Kirill Balunov]

I've asked the same question on StackOverflow, but it seems to me that it
is opinion based and will be ignored. So I ask for advice here:

Since PEP 526 -- Syntax for Variable Annotations
  was approved, in Python 3.6+
it is possible to provide type hint information in the form *x: int*, also
the PEP says "However, annotating a local variable will cause the
interpreter to always make it local to the scope and leaves the variable
uninitialized". Therefore in Python 3.6+ it is syntactically legal to
write:

def outer():
x: int
def inner():
nonlocal x
x = 10
inner()
print(x)

while the above snippet is semantically more equivalent to:

def outer():
#x
def inner():
nonlocal x
x = 10
inner()
print(x)

Which is obviously a *SyntaxError: no binding for nonlocal 'x' found`*,
sorry for the pun. Also there is nothing said about this style in PEP 8 and
Python 3.6 docs. So should I consider this as a bug, or an implementation
detail (side effect), or a wart, or a feature?

To clarify the purpose of the question - we can not come to a consensus and
I would like to hear your opinion and possible pitfalls, if any, if we
choose to use this form in our codebase.

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python: asyncio and Tkinter

[c.buhtz]

X-Post:
 

Dear Chris.

On 2017-12-21 00:42 Chris Angelico  wrote:
> I would recommend threading. You can run your GUI event loop on one
> thread, and your network I/O loop on another thread.

Thank you very much for your answer. It also came to my mind to
separate each loop in it's own thread. But I am for a way from being a
professional in that topics.

I created a minimal working example to ask that question on
StackOVerflow, too. There is no multithreading in that example.


Now I modified that example "based" on your solution. But the GUI is
still freezing why my tasks are working. Your solution is a bit to
complex for me and use some technics (the server think) I don't know.

Could you please throw an eye on the current state of my code?

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

Re: correctness proof for alpha-beta algorithm

[namenobodywants]

On Tuesday, December 19, 2017 at 3:28:39 PM UTC-8, Steve D'Aprano wrote:

> Does this have anything specifically to do with Python programming?

i'm working on a game-playing script (ie: in python), i want to incorporate 
pruning into my search algorithm, and i'd like to understand why it works; i'm 
not sure if that counts

> If not, why are you asking here? Do you think that Python programmers are
> especially well-known for their hard-core formal academic methodology?

maybe i just think python programmers are smart or well-informed or something 
like that

> We're pretty accepting of off-topic posts here, especially when they evolve
> naturally from an on-topic post. But in future, if you're going to *start* an
> off-topic thread from the first post, it would be polite to label it such
> with an "[OT]" or "Off-topic" prefix to the subject line.

can do

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

Re: correctness proof for alpha-beta algorithm

[namenobodywants]

On Tuesday, December 19, 2017 at 5:34:17 PM UTC-8, Paul Rubin wrote:

> It frankly sounds like homework.

https://en.wikipedia.org/wiki/Theorem
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: correctness proof for alpha-beta algorithm

[Bill]

namenobodywa...@gmail.com wrote:

On Tuesday, December 19, 2017 at 3:28:39 PM UTC-8, Steve D'Aprano wrote:


Does this have anything specifically to do with Python programming?

i'm working on a game-playing script (ie: in python), i want to incorporate 
pruning into my search algorithm, and i'd like to understand why it works; i'm 
not sure if that counts


Based upon your posts, I think you should just write your own. Then you 
can be sure that it will work. That's better than working with something 
that you don't understand.



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

Re: correctness proof for alpha-beta algorithm

[Steve D'Aprano]

On Thu, 21 Dec 2017 08:37 am, Bill wrote:

> namenobodywa...@gmail.com wrote:
>> On Tuesday, December 19, 2017 at 3:28:39 PM UTC-8, Steve D'Aprano wrote:
>>
>>> Does this have anything specifically to do with Python programming?
>> i'm working on a game-playing script (ie: in python), i want to incorporate
>> pruning into my search algorithm, and i'd like to understand why it works;
>> i'm not sure if that counts
> 
> Based upon your posts, I think you should just write your own. Then you
> can be sure that it will work. 

How long did you say you've been programming? Perhaps you've heard of
something we in the programming world call "bugs".




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

property decorator?

[Irv Kalb]

I am trying  to work through the concept of the @property decorator with 
respect to object oriented programming.

I believe that I understand how the @property and @.setter work - 
and that they are used to turn what looks like direct access to instance 
variables into method calls in an object.It seems like these two decorators 
are essentially fancy substitutes for traditional getter and setter methods.  
But, I'm having a hard time understanding why these names were chosen. 

I have the following example code:


class Employee():

def __init__(self, name, salary):
self.__name = name
self.__salary = salary

@property
def salary(self):
print('Getting salary of', self.__name, 'which is:', self.__salary)
return self.__salary

@salary.setter
def salary(self, newSalary):
print('Setting salary of', self.__name, 'to:', newSalary)
self.__salary = newSalary


# Test code:
employee1 = Employee('Joe Schmoe', 9)
employee2 = Employee('Jane Smith', 123456)

print(employee1.salary)
print(employee2.salary)

employee1.salary = 10
employee2.salary = 22

print(employee1.salary)
print(employee2.salary)


When it runs, I get the results I expect:

Getting salary of Joe Schmoe which is: 9
9
Getting salary of Jane Smith which is: 123456
123456
Setting salary of Joe Schmoe to: 10
Setting salary of Jane Smith to: 22
Getting salary of Joe Schmoe which is: 10
10
Getting salary of Jane Smith which is: 22
22


My questions about this are really historical.  From my reading, it looks like 
using an @property decorator is a reference to an older approach using a built 
in "property" function.  But here goes:

1) Why were these decorator names chosen?  These two names @property and 
@.setter don't seem to be very clear to me.  At a minimum, they don't 
match.  Wouldn't decorator names like @.getter and @.setter have 
been better - more explicit?

2)  Alternatively, if the getter was going to use the @property decorator, then 
it would seem complimentary  to have the decorator name for the associated 
setter function to have the word "property" in its also, something like 
@propertySetter.  

3)  If I create a method with the @property decorator, is there anything else 
that is implied about the name of the method other than you can now refer to 
the . - which calls the appropriate method?  My 
guess/understanding is that in my example above, "salary" is considered the 
property name, which is how you would refer to it outside of the object. Inside 
the class, you use the property name as the name of both the setter and the 
getter methods.  Is that the right way to think about it?


Finally, it seems very odd to me that when you use the @property decorator and 
the @.setter, that both of the methods that are decorated need to 
have the same name (but of course different set of parameters.)  As a teacher, 
this seems like it would be an extremely difficult concept to get across to 
students, as this does not work the same way as other Python functions (and 
methods).  Without a decorator, the second function of the same name overrides 
an earlier function of the same name, as in this simple example:

def myFunction( ):
print('In first version of myFunction')

def myFunction( ):
print('In second version of myFunction')

myFunction()

Which prints:  In second version of myFunction




My most recent language before Python was ActionScript 3 (the language of 
Flash).  It implemented a similar concept of being able to use what appeared to 
be an explicit data reference which turns into a method call, like this example 
(from StackOverflow):

private var _loggy:String;

public function get loggy ():String
{
  return _loggy;
}

public function set loggy ( loggy:String ):void
{
  // checking to make sure loggy's new value is kosher etc...
  _loggy = loggy;
}
This syntax made the concept easy to understand and implement in an 
ActionScript class (even though it also uses the same name for both function).

I do NOT want to start any kind of language flame war.  I am really just trying 
to understand the reasons behind why this concept is implemented in Python this 
way, so that I can wrap my head around it and teach it effectively in my 
classes.

Irv

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

Re: property decorator?

[Rob Gaddi]

On 12/20/2017 03:56 PM, Irv Kalb wrote:

I am trying  to work through the concept of the @property decorator with 
respect to object oriented programming.

I believe that I understand how the @property and @.setter work - 
and that they are used to turn what looks like direct access to instance variables 
into method calls in an object.It seems like these two decorators are essentially 
fancy substitutes for traditional getter and setter methods.  But, I'm having a hard 
time understanding why these names were chosen.


> [snip]


My questions about this are really historical.  From my reading, it looks like using an 
@property decorator is a reference to an older approach using a built in 
"property" function.  But here goes:

1) Why were these decorator names chosen?  These two names @property and @.setter 
don't seem to be very clear to me.  At a minimum, they don't match.  Wouldn't decorator names 
like @.getter and @.setter have been better - more explicit?

2)  Alternatively, if the getter was going to use the @property decorator, then it would 
seem complimentary  to have the decorator name for the associated setter function to have 
the word "property" in its also, something like @propertySetter.

3)  If I create a method with the @property decorator, is there anything else that is implied about 
the name of the method other than you can now refer to the . - which 
calls the appropriate method?  My guess/understanding is that in my example above, "salary" 
is considered the property name, which is how you would refer to it outside of the object. Inside the 
class, you use the property name as the name of both the setter and the getter methods.  Is that the 
right way to think about it?


Finally, it seems very odd to me that when you use the @property decorator and the 
@.setter, that both of the methods that are decorated need to 
have the same name (but of course different set of parameters.)  As a teacher, this 
seems like it would be an extremely difficult concept to get across to students, as 
this does not work the same way as other Python functions (and methods).  Without a 
decorator, the second function of the same name overrides an earlier function of the 
same name, as in this simple example:


> [snip]
>

Irv



It's because of how Python implements decorators.  When I write

class C:
  def foobar(self):
pass

I create a binding in the local scope of class C with the name "foobar" 
that holds a function object.  We call this a "local variable" in 
keeping with other languages, but it's not really the same as it would 
be in like C, it's a reference in the local namespace to some other 
object.  When I decorate that foobar instead:


class C:
  @property
  def foobar(self):
pass

That variable now, instead of referencing a function object, references 
an instance of type 'property' that holds a reference to the original 
foobar method as it's "_getter".  When I expand that to


class C:
  @property
  def foobar(self):
return self.__foobar

  @foobar.setter
  def foobar(self, value):
self.__foobar = value

The second decoration calls the 'setter' method of the property instance 
stored in variable name foobar.  That method assigns the new method to 
the "_setter" of that property instance and returns the updated 
property, which is assigned redundantly to the variable name foobar.



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

How to edit a function in an interactive python session?

[Peng Yu]

Hi,

R has the function edit() which allows the editing of the definition
of a function. Does python have something similar so that users can
edit python functions on the fly? Thanks.

https://www.rdocumentation.org/packages/utils/versions/3.4.3/topics/edit

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

Re: How to edit a function in an interactive python session?

[Ben Finney]

Peng Yu  writes:

> R has the function edit() which allows the editing of the definition
> of a function. Does python have something similar so that users can
> edit python functions on the fly? Thanks.

That would depend on which interactive tool you're using.

The typical Python REPL [0] tools – interactive ‘python3’, the enhanced
‘ipython3’ tool, and so on – do not, to my knowledge, retain the source
code that you enter. They pass it immediately to the Python compiler,
and receive back the compiled code object, and use that. The source code
is discarded by the time the code is run.

So any tool that does what you propose will need to keep that source
code around indefinitely, in anticipation of being asked to edit and
re-compile it.

I think you're asking not for a REPL, but a tool at a higher level known
as an IDE [1]. You can use any good IDE, such as Emacs, to edit code and run
it interactively.


[0] Read, Evaluate, Print, then Loop.
[1] Interactive Development Environment.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

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

Re: How to edit a function in an interactive python session?

[Steve D'Aprano]

On Thu, 21 Dec 2017 12:42 pm, Peng Yu wrote:

> Hi,
> 
> R has the function edit() which allows the editing of the definition
> of a function. Does python have something similar so that users can
> edit python functions on the fly? Thanks.
> 
> https://www.rdocumentation.org/packages/utils/versions/3.4.3/topics/edit

No.

In the standard interactive interpreter, you can only re-enter the function,
either re-typing it, or using the readline "history" to call up each line
again. (This may not work under Windows.)

iPython or Jupyter may offer extra editing functionality.

Or you could try creating your own. This might be a good place to start:

https://mail.python.org/pipermail/python-list/2014-September/677841.html

http://code.activestate.com/recipes/578926-call-out-to-an-external-editor/

 
Read the full thread -- it has lots of useful information.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: property decorator?

[Ian Kelly]

On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb  wrote:
> My questions about this are really historical.  From my reading, it looks 
> like using an @property decorator is a reference to an older approach using a 
> built in "property" function.  But here goes:
>
> 1) Why were these decorator names chosen?  These two names @property and 
> @.setter don't seem to be very clear to me.  At a minimum, they don't 
> match.  Wouldn't decorator names like @.getter and @.setter have 
> been better - more explicit?

That wouldn't work because @.getter causes Python to look up the
 variable within the class scope and then its getter attribute.
But  hasn't been defined yet and won't be until after the getter
has been created.

> 2)  Alternatively, if the getter was going to use the @property decorator, 
> then it would seem complimentary  to have the decorator name for the 
> associated setter function to have the word "property" in its also, something 
> like @propertySetter.

Perhaps this could have been done, but unlike the getter, the setter
is being defined on a property that now already exists. In this case
 has to be referenced somewhere within the decorator or else the
setter property will simply replace the getter property, rather than
augment and then replace it.

I suppose what it boils down to is that there's no particular reason
to look up "property" again since the getter already declared that
this is a property.

> 3)  If I create a method with the @property decorator, is there anything else 
> that is implied about the name of the method other than you can now refer to 
> the . - which calls the appropriate method?  My 
> guess/understanding is that in my example above, "salary" is considered the 
> property name, which is how you would refer to it outside of the object. 
> Inside the class, you use the property name as the name of both the setter 
> and the getter methods.  Is that the right way to think about it?

No, "salary" is the property name regardless of whether you're
referring to it from inside or outside of the class definition. With
the notable exceptions of super() and double-underscore name mangling,
Python generally doesn't care about *where* an attribute or method
reference is made from.

> Finally, it seems very odd to me that when you use the @property decorator 
> and the @.setter, that both of the methods that are decorated 
> need to have the same name (but of course different set of parameters.)  As a 
> teacher, this seems like it would be an extremely difficult concept to get 
> across to students, as this does not work the same way as other Python 
> functions (and methods).  Without a decorator, the second function of the 
> same name overrides an earlier function of the same name, as in this simple 
> example:

Strictly speaking, they don't *need* to have the same name. This works:

class Employee():

def __init__(self, name, salary):
self.__name = name
self.__salary = salary

@property
def salary_one(self):
print('Getting salary of', self.__name, 'which is:', self.__salary)
return self.__salary

@salary_one.setter
def salary_two(self, newSalary):
print('Setting salary of', self.__name, 'to:', newSalary)
self.__salary = newSalary


The result would be that Employee has a get-only property named
salary_one since it was never overwritten, and a get-set property
named salary_two that combines the getter from salary_one with a new
setter. If you wanted to, you could then:

del salary_one

and only salary_two would exist as in the usual case. But this is
mostly just for demonstration of the object model; there's no
practical reason to use different names for each.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: property decorator?

[Chris Angelico]

On Thu, Dec 21, 2017 at 2:38 PM, Ian Kelly  wrote:
> On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb  wrote:
>> 2)  Alternatively, if the getter was going to use the @property decorator, 
>> then it would seem complimentary  to have the decorator name for the 
>> associated setter function to have the word "property" in its also, 
>> something like @propertySetter.
>
> Perhaps this could have been done, but unlike the getter, the setter
> is being defined on a property that now already exists. In this case
>  has to be referenced somewhere within the decorator or else the
> setter property will simply replace the getter property, rather than
> augment and then replace it.
>
> I suppose what it boils down to is that there's no particular reason
> to look up "property" again since the getter already declared that
> this is a property.

It's more than that. It's actually not easy to locate something by its
name while you're in process of setting it up. Consider:

class Demo:
@getter
def foo(self):
...
@setter
def foo(self, value):
...

Only one thing can be bound to Demo.foo, which means that that one
thing has to be a property capable of calling on the getter and the
setter. That means that when setter(foo) is called, it would need to
locate the pre-existing "foo" property and augment it. That's actually
pretty hard to do reliably (remember that there are many contexts in
which this can be called).

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

Re: property decorator?

[Cameron Simpson]

On 20Dec2017 15:56, Irv Kalb  wrote:

I am trying  to work through the concept of the @property decorator with 
respect to object oriented programming.

I believe that I understand how the @property and @.setter work - 
and that they are used to turn what looks like direct access to instance variables 
into method calls in an object.It seems like these two decorators are essentially 
fancy substitutes for traditional getter and setter methods.


That is correct. In a "pure" OO environment, all internal state would be 
hidden, and accessed and modified by getters and setters, or by side effects of 
other methods.


Python, like many languages, exposes the internal attributes of objects. Which 
is convenient, and I for one find pure "getter/setter" methods cumbersome and 
tedious.


A property lets you do a few things: to present some state that lends itself to 
looking like a plain variable, as a variable; to put constraints on the values 
set on such a variable (eg to raise exceptions for forbidden values) or to have 
side effects (eg reducing a Semaphore's capacity might block until enough is 
released); and to promote something that was formerly a plain old attribute 
with a value into something more complex while keeping the previous API of 
accessing the attribute directly.



But, I'm having a hard time understanding why these names were chosen.

[...]
My questions about this are really historical.  From my reading, it looks like 
using an @property decorator is a reference to an older approach using a built 
in "property" function.


Maybe so; I cannot speak to this. But a property is a well defined Python 
concept. The "property" decorator is a builtin function (well, a clas sinstance 
constructor) for creating one from a function, and seems pretty naturally named 
to me:


 https://docs.python.org/3/library/functions.html#property


But here goes:

1) Why were these decorator names chosen?  These two names @property and @.setter 
don't seem to be very clear to me.  At a minimum, they don't match.  Wouldn't decorator names 
like @.getter and @.setter have been better - more explicit?


Yes, but there's a bootstrap issue: having @.getter work immediately 
implies that .getter is already an existing function, because the @ 
syntax applies a function to another function, returning a function. And 
"getter" is at the least a public name, possibly already in use for something 
else.


Don't forget that @foo is a general system for wrapping functions, and that 
@property is just one example. So if you have a class:


 class Klass:
   @foo
   def method(self, bah):
 ...

it creates the function "method", and then computes "foo(method)", which 
normally would return another function that itself calls the original "method", 
and defines "Klass.method" as that new function.


So if you do this:

 class Klass:
   @property
   def method(self):
 return 3

That defines Klass.method as a property. Until it is a property, you can't talk 
about Klass.method.setter. And you need to be specific: "method.setter" is a 
setter for that specific property ("method").


You can't do this:

 @method.getter
 def method(self):
   return 3

because "method" is not yet defined when you say "method.getter".

First you need to make it a property, which must be done with something _not_ 
named "method", because that name doesn't exist to start with. And that 
something is the builtin function "property", which is used to create 
properties via the decoator syntax.


_After_ that property is made, _then_ you can talk about "method.setter" 
because properties have a ".setter" method which constructs property setting 
functions.


Hoping this make the _process_ more clear, particularly that "method" isn't 
known to start with, therefore "method.getter" is not a name you can use.


2)  Alternatively, if the getter was going to use the @property decorator, 
then it would seem complimentary  to have the decorator name for the 
associated setter function to have the word "property" in its also, something 
like @propertySetter.


Because . is a property now, the existingence of a .setter 
function is implied; onemerely has to use it to define the setter method.



3)  If I create a method with the @property decorator, is there anything else that is 
implied about the name of the method other than you can now refer to the 
. - which calls the appropriate method?


It is the ability to refer to . which is what makes a 
property a property. As a property, it also has ..setter and 
..deleter defined, which are functions which can be used as 
decorators to define setter and deleter methods.


My guess/understanding is that in my example above, "salary" is considered the 
property name, which is how you would refer to it outside of the object.  
Inside the class, you use the property name as the name of both the setter and 
the getter methods.  Is that the right way to think about it?


Usually I think of the property "salary" as a

Re: correctness proof for alpha-beta algorithm

[Bill]

Steve D'Aprano wrote:

On Thu, 21 Dec 2017 08:37 am, Bill wrote:


namenobodywa...@gmail.com wrote:

On Tuesday, December 19, 2017 at 3:28:39 PM UTC-8, Steve D'Aprano wrote:


Does this have anything specifically to do with Python programming?

i'm working on a game-playing script (ie: in python), i want to incorporate
pruning into my search algorithm, and i'd like to understand why it works;
i'm not sure if that counts

Based upon your posts, I think you should just write your own. Then you
can be sure that it will work.

How long did you say you've been programming? Perhaps you've heard of
something we in the programming world call "bugs".


You're supposed to get rid those those.  Use Raid!  : )




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

Re: correctness proof for alpha-beta algorithm

[Chris Angelico]

On Thu, Dec 21, 2017 at 3:40 PM, Bill  wrote:
> Steve D'Aprano wrote:
>>
>> On Thu, 21 Dec 2017 08:37 am, Bill wrote:
>>
>>> namenobodywa...@gmail.com wrote:

 On Tuesday, December 19, 2017 at 3:28:39 PM UTC-8, Steve D'Aprano wrote:

> Does this have anything specifically to do with Python programming?

 i'm working on a game-playing script (ie: in python), i want to
 incorporate
 pruning into my search algorithm, and i'd like to understand why it
 works;
 i'm not sure if that counts
>>>
>>> Based upon your posts, I think you should just write your own. Then you
>>> can be sure that it will work.
>>
>> How long did you say you've been programming? Perhaps you've heard of
>> something we in the programming world call "bugs".
>
>
> You're supposed to get rid those those.  Use Raid!  : )

I tried using software RAID once, but my code was still buggy...

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

Re: How to edit a function in an interactive python session?

[Rustom Mody]

On Thursday, December 21, 2017 at 7:12:24 AM UTC+5:30, Peng Yu wrote:
> Hi,
> 
> R has the function edit() which allows the editing of the definition
> of a function. Does python have something similar so that users can
> edit python functions on the fly? Thanks.
> 
> https://www.rdocumentation.org/packages/utils/versions/3.4.3/topics/edit

Dunno What exactly you are asking
And I suspect an “impedance mismatch” between the answers you are receiving and
what you seek.


Firstly on briefly looking at the R-docs that you quote I see that it does not
guarantee a faithful 'deparsing'… which I interpret as saying that R may
present to you a different (looking) function on (re) editing than what you 
typed

The real problem is that in the scale of religious dogmas python community
puts inter-OS portability/stability etc over and above development environment
This means that the tutorial is woefully inadequate (mostly by omission) in
terms of recommending a suitable dev environment.
And almost suggests that the basic interactive python shell is enough for 
writing/trying out python code.

This is patently false

An experienced programmer either:
-  Writes scripts (or GUI programs or web-apps or ...) using a full-featured 
editor like vim
Or 
- Uses a dev-environment — IDLE, emacs, pycharm, pydev, jupyter, org-babel… 
probably a dozen reasonable choices and hundreds of less reasonable ones

In either of these cases the question that you ask does not arise because the
code you are working on is always there "in another window"
- one click away from being tried out
- one click away from being edited (in its actual and not "deparsed" form)


I tend to use emacs
My students suffer me and my habits
As an editor its really clunky obsolete and asinine
But its not an editor; its an OS and in that sphere there is nothing else for 
competition
However I would not make this recommendation for emacs over the net
[Learning a dev-environment is like learning a musical instrument : not 
convenient over the net]


To a beginner I would recommend IDLE by default unless there is significant 
data 
pushing another choice

And if you try that you will see your question becomes automatically answered
(or irrelevant)
-- 
https://mail.python.org/mailman/listinfo/python-list