Re: Python is DOOMED! Again!

[Chris Angelico]

On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano
 wrote:
> I consider return type to be part of the function signature. The signature
> of a function is the parameters it accepts and the result it returns.

It is, but there are times when it isn't significant. For instance,
C++ overloaded functions are distinguished by their function
signatures, but *not* including the return values (nor several other
aspects).

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

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Chris Angelico wrote:

> On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano
>  wrote:
>> I consider return type to be part of the function signature. The
>> signature of a function is the parameters it accepts and the result it
>> returns.
> 
> It is, but there are times when it isn't significant. For instance,
> C++ overloaded functions are distinguished by their function
> signatures, but *not* including the return values (nor several other
> aspects).

C++ is an unholy abomination unto Nuggan :-)


-- 
Steve

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

Re: Running a .py file iteratively at the terminal

[Philip Keogh]

On Mon, 26 Jan 2015, varun...@gmail.com wrote:
> Thanks a lot Mark but that would be a bit trivial. How can I run the
> same file multiple times? Or if I need to run two commands:
> srva@hades:~$ python NFV_nw_eu_v3_14_1_15.py --output eu_v3_14_1_15
> --demand demands_v3_21_1_15.xml --xml nobel-eu.xml
>srva@hades:~$ python NFV_v3_7_10_14.py -l log --lp --xml eu_v3_14_1_15.xml 
> repeatedly, how can I do that? Can I write a script to perform this
> function?If so, can you please help me with it?  The first command
> generates an output file eu_v3 and the second file feeds it to the
> solver. This is what I intend to do multiple times. I hope I have
> explained it this time in a much better way. I'm sorry English is my
> second language and I have some problems in expressing myself at
> times.
> 
> Thank You
> 

Have you read about Bash shell brace expansion, or a one-liner loop? A
simple wrapper script could easily accomplish what you seem to be
attempting to do.

For more, see:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html
http://www.linuxjournal.com/content/bash-brace-expansion
http://wiki.bash-hackers.org/syntax/expansion/brace
http://tldp.org/LDP/abs/html/loops1.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Re: Comparisons and sorting of a numeric class....

[Andrew Robinson]

On 01/26/2015 02:22 PM, Ian Kelly wrote:



On Jan 26, 2015 6:42 AM, "Andrew Robinson" > wrote:

> ...

If you're going to descend into insults and name-calling, then I'm not 
going to waste any more of my time on this thread.




I don't believe I've actually, intentionally, insulted you.  That's 
generally not in my nature, although annoyance sometimes comes out.


If my response to D'Aprano's abrasive remarks upset you -- well, sorry.  
It honestly wasn't aimed at you and it wasn't derogatory name calling.  
eg:  If you mean 'bool', instead of 'Boole' that's just because Python 
does it.


The restriction on inheriting from bool isn't likely to change. There 
have been several suggestions as to how you can do what you want. I 
recommend you pick one and get on with it.




FYI:  I already have implemented the code twice, so there's no need to 
continue the conversation for my sake.
I got 'on' with it a long time ago; but thanks for the advice for what 
it's worth.


I hope you enjoyed seeing a C++ type cast of a non bool type into a bool 
that can be used as a bool at leisure, although if you've already stated 
your pleasure or displeasure -- it may take me a while to find the email 
in the backlog so don't feel pressure to repeat yourself.


--Cheers.

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

aging Products And skin care products

[morristurnies]

Belladerm all your skin's brands Skin Care Tips products. You will likely
realize that these items are mostly filled up with chemicals and
dysfunctional water-content. Using compounds to your skin could worsen it
and make it dried or cause it make oils to compensate for the dryness. These
products you are utilizing on your skin to enhance your appearance may
really be making things worse. If you utilize makeup, read the brands of the
products you utilize and eliminate any powder- based makeup since your pores
can clog.

Belladerm is a wholesome quite essential to achieve a wholesome looking
skin. Contain plenty of vegetables and fruits in to your diet menu. Also,
take multivitamins over a regular schedule. Try to avoid fried and fatty
food as much as possible. Create a regular exercise regime to naturally
cleanse the human body. Aside for these tips, increase your water
absorption. Water is among the finest ingredients for the skin. Avoid
dehydration causing elements including coffee and liquor.

http://www.alrastc.net/belladerm-skincare/



--
View this message in context: 
http://python.6.x6.nabble.com/aging-Products-And-skin-care-products-tp5084350.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Re: Comparisons and sorting of a numeric class....

[Gregory Ewing]

Andrew Robinson wrote:

The spelling caveat is great -- and in Python the object named in bool's 
honor is spelled bool (lowercase too). ;)


That doesn't change the fact that the man was called
George Boole (not Charles!). If you're going to refer
to him by name, it's only courteous to make some effort
to get it right.

http://en.wikipedia.org/wiki/George_Boole

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

ANN: JuliaBase -- LIMS for specimen-based research published as open source

[Torsten Bronger]

We are proud to announce that our in-house samples database solution
is now published as open source software (AGPL).  It is a
Python/Django-based framework for creating Web databases for
samples.  So far, it is used successfully by four in-house
departments.

For all the details and a demo, visit .

The highlights include:

- maximal flexibility for being adapted perfectly to your production and
  measurement setups, and to your workflows; (that's the reason why it is a
  programming framework rather than a turnkey application)
- keeps track of samples across sample splits
- support for pre-evaluating raw data and creating plots
- arbitrarily complex searches made easy, e.g. “find all samples with infrared
  measurements, deposited together with a sample on glass substrate with a
  conductivity greater than 10^-6 S/cm; oh yes, and only from this year and
  made by John”
- export to spreadsheets
- automatic lab notebooks
- server interaction with other programs through an HTTP/JSON interface

JuliaBase's sources include an "example institute" that programmers
can use as a starting point.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Idiomatic backtracking in Python

[sjmsoft]

On Sunday, January 25, 2015 at 4:15:58 PM UTC-4, Johannes Bauer wrote:
> Hi folks,
> 
> I have a problem at hand that needs code for backtracking as a solution.
> And I have no problem coding it, but I can't get rid of the feeling that
> I'm always solving backtracking problems in a non-Pythonic
> (non-idiomatic) way. So, I would like to ask if you have a Pythonic
> approach to backtracking problems? If so, I'd love to hear your solutions!

When I think of backtracking, I think of Prolog (to which backtracking is 
central).  You could use PySWIP to run SWI-Prolog from your Python program.  
Not idiomatic Python backtracking, of course, but it would get the job done, 
and Prolog's backtracking is reliable and well-described.  It would help if you 
already know a bit of Prolog or are keen to learn.

Cheers,
  Steve J. Martin


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

Is there a more elegant way to spell this?

[Neal Becker]

Is there a more elegant way to spell this?

for x in [_ for _ in seq if some_predicate]:


-- 
-- Those who don't understand recursion are doomed to repeat it

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

Re: Is there a more elegant way to spell this?

[Chris Warrick]

On Jan 27, 2015 2:16 PM, "Neal Becker"  wrote:
>
> Is there a more elegant way to spell this?
>
> for x in [_ for _ in seq if some_predicate]:

for x in seq:
if some_predicate:
do_something_to(x)

-- 
Chris Warrick 
Sent from my Galaxy S3.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Jean-Michel Pichavant]

- Original Message -
> From: "Neal Becker" 
> To: python-list@python.org
> Sent: Tuesday, 27 January, 2015 2:15:12 PM
> Subject: Is there a more elegant way to spell this?
> 
> Is there a more elegant way to spell this?
> 
> for x in [_ for _ in seq if some_predicate]:

You could use a generator expression

for x in (_ for _ in seq if some_predicate):

This is very similar but it prevents python from creating a new list.


JM



-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Rustom Mody]

On Tuesday, January 27, 2015 at 6:45:41 PM UTC+5:30, Neal Becker wrote:
> Is there a more elegant way to spell this?
> 
> for x in [_ for _ in seq if some_predicate]:

Depends on what follows the ':'

In the trivial case all thats outside the comprehension can be dropped:

>>> [x for x in [y for y in range(10) if y % 2 == 0]]
[0, 2, 4, 6, 8]
>>> [y for y in range(10) if y % 2 == 0]
[0, 2, 4, 6, 8]
>>> 

Or

>>> [x*x for x in [y for y in range(10) if y % 2 == 0]]
[0, 4, 16, 36, 64]
>>> [y*y for y in range(10) if y % 2 == 0]
[0, 4, 16, 36, 64]
>>> 
> 
> 
> -- 
> -- Those who don't understand recursion are doomed to repeat it

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

Re: Is there a more elegant way to spell this?

[Jussi Piitulainen]

Neal Becker writes:

> Is there a more elegant way to spell this?
> 
> for x in [_ for _ in seq if some_predicate]:

If you mean some_predicate(_), then possibly this.

for x in filter(some_predicate, seq):
   handle(x)

If you mean literally some_predicate, then perhaps this.

if some_predicate:
   for x in seq:
  handle(x)

Unless you also have in mind an interesting arrangement where
some_predicate might change during the loop, like this.

for x in [_ for _ in seq if some_predicate]:
...
some_predicate = fubar(x)
...

Then I have nothing to say.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Neal Becker]

Jussi Piitulainen wrote:

> Neal Becker writes:
> 
>> Is there a more elegant way to spell this?
>> 
>> for x in [_ for _ in seq if some_predicate]:
> 
> If you mean some_predicate(_), then possibly this.
> 
> for x in filter(some_predicate, seq):
>handle(x)
> 

I like this best, except probably even better:

for x in ifilter (some_predicate, seq):

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

Re: Is there a more elegant way to spell this?

[Jussi Piitulainen]

Neal Becker writes:
> Jussi Piitulainen wrote:
> > Neal Becker writes:
> > 
> >> Is there a more elegant way to spell this?
> >> 
> >> for x in [_ for _ in seq if some_predicate]:
> > 
> > If you mean some_predicate(_), then possibly this.
> > 
> > for x in filter(some_predicate, seq):
> >handle(x)
> > 
> 
> I like this best, except probably even better:
> 
> for x in ifilter (some_predicate, seq):

That's in Python 2 and in itertools, I think. In Python 3, filter is a
built-in and returns a filter object.

>>> f = filter(None, map(int, '102030'))
>>> f

>>> next(f)
1
>>> list(f)
[2, 3]
>>> list(f)
[]
>>> 
-- 
https://mail.python.org/mailman/listinfo/python-list

kivy: python on android

[Rustom Mody]

Following some posts here I thought I'd try python on android via kivy.

Followed the tutorials -- involved a couple of GBs(!!) of downloads
using something called buildozer

Finally got a hello world running on a phone -- Yay!

Now when I try to go from hello world to something a more (kivy-examples run
nicely on ubuntu), buildozer starts downloading those GBs again!!

Does anyone have a clue on where I am clueless?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unicode question

[random832]

On Tue, Jan 27, 2015, at 00:17, Rehab Habeeb wrote:
> Hi there python staff
> does python support arabic language for texts ? and what to do if it
> support it?
> i wrote hello in Arabic using codeskulptor and the powershell just for
> testing and the same error appeared( a sytanx error in unicode)!!

Python itself supports arabic just fine, but the MS Windows console in
general, and Python's implementation of it in particular, have poor
support for many aspects of unicode, so it's important to define exactly
what you are trying to do.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unicode question

[Mark Lawrence]

On 27/01/2015 16:13, random...@fastmail.us wrote:

On Tue, Jan 27, 2015, at 00:17, Rehab Habeeb wrote:

Hi there python staff
does python support arabic language for texts ? and what to do if it
support it?
i wrote hello in Arabic using codeskulptor and the powershell just for
testing and the same error appeared( a sytanx error in unicode)!!


Python itself supports arabic just fine, but the MS Windows console in
general, and Python's implementation of it in particular, have poor
support for many aspects of unicode, so it's important to define exactly
what you are trying to do.



People might find this http://bugs.python.org/issue1602 and hence this 
https://github.com/Drekin/win-unicode-console useful.  The latter is 
available on pypi.


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

Mark Lawrence

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

Re: Python is DOOMED! Again!

[random832]

On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote:
> I consider return type to be part of the function signature. The
> signature 
> of a function is the parameters it accepts and the result it returns.

It's part of it, but not the whole of it, and early C compilers had no
information about the parameters except from the call site itself. You
could even call the same function multiple different ways (this was
later formalized with variadic functions).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[random832]

On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> > (header files in the 1970s didn't even actually include function
> > signature information) - which did not even participate in compilation
> > at all.
> 
> If C compilers didn't use the header files, what were they for?

My sentence may have been phrased in a confusing way. C compilers did
use the header files, and the header files did not include _most_
function signature information (they only included the return type of
functions whose return type was not int. Any function not declared was
assumed to return int). Lint libraries did contain function signature
information, and were not used for compilation (but rather only for
running lint).

The void type didn't exist either - a function with no declared return
type could either return int or return nothing at all. A call site
attempting to use the value of such a function would get whatever
arbitrary value was in r0. Lint libraries also included return
statements for such functions to determine if they returned values or
not.

Here is an example of a lint library:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/llib-lc

Here is stdio.h from the same era.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/stdio.h

Headers also would often not include function declarations even for
functions that did have non-int return types. For example, time.h had no
function declarations despite many of the time library functions
returning pointers, it only contained the definition of struct tm. There
was no stdlib.h at all - you were expected to declare e.g. "char
*malloc();" yourself if you needed it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[random832]

On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> random...@fastmail.us wrote:
> - lexical analysis has to look for twice as many files (it has to 
>   hit the hard drive for a stub file before looking at the source),
>   and we know from importing that file system access is a 
>   significant and expensive part of the process.

The idea is that the type hinting files would not participate in
execution at all, only static analysis, so the interpreter doesn't need
to look for these things at all, it only needs to ignore them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 27/01/2015 17:26, random...@fastmail.us wrote:

On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote:

I consider return type to be part of the function signature. The
signature
of a function is the parameters it accepts and the result it returns.


It's part of it, but not the whole of it, and early C compilers had no
information about the parameters except from the call site itself. You
could even call the same function multiple different ways (this was
later formalized with variadic functions).



Back to that old Whitesmith's compiler.  It's certainly very interesting 
to see what the assembler looks like when you forget the ampersand, the 
compiler doesn't throw an error, and so the entire structure instead of 
a single pointer gets passed into your function.  Not so much passed by 
value, or reference, or object, but complete foul up :)


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

Mark Lawrence

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

Re: Is there a more elegant way to spell this?

[Rob Gaddi]

On Tue, 27 Jan 2015 14:20:10 +0100
Chris Warrick  wrote:

> On Jan 27, 2015 2:16 PM, "Neal Becker"  wrote:
> >
> > Is there a more elegant way to spell this?
> >
> > for x in [_ for _ in seq if some_predicate]:
> 
> for x in seq:
> if some_predicate:
> do_something_to(x)
> 
> -- 
> Chris Warrick 
> Sent from my Galaxy S3.
> 
Or the somewhat less indenty

for x in seq:
if not some_predicate: continue
do_something_to(x)

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
random...@fastmail.us says...
> 
> On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
> > random...@fastmail.us wrote:
> > - lexical analysis has to look for twice as many files (it has to 
> >   hit the hard drive for a stub file before looking at the source),
> >   and we know from importing that file system access is a 
> >   significant and expensive part of the process.
> 
> The idea is that the type hinting files would not participate in
> execution at all, only static analysis, so the interpreter doesn't need
> to look for these things at all, it only needs to ignore them.

Like Steven, I do not agree with the idea of adding files for the 
purposes of static analysis. But you make an important point.

Static analysis cannot and should not clutter executable code. Static 
analysis doesn't require code execution. The Python interpreter doesn't 
need to be called in. It is for this reason that it makes absolutely no 
sense to for type hints to be mixed with our code. Let them reside in 
comments, docstrings, external files, whatever. But never in our code.

I'm actually baffled that PEP 484 came into existence, let alone it 
having any kind of supporter. Here we have a syntax that even requires 
changes to the interpreter so it can safely ignore all the type hinting 
clutter that is going to be added by anyone wanting to perform static 
analysis.

And we should also be careful around the argument that type hints are 
optional.

An optional feature says nothing of its requirements. The requirements 
for PEP 484 are heavy. Not only will they force an update to the 
interpreter, but will also force many users to reformate their function 
headers in order for them to become bareable to the eye. In fact, no 
longer will you look at function definitions like you did before.

And an optional feature says nothing of its usage patterns. Type hints 
may be optional, but they may become a requirement for many projects. In 
fact, the more complex your project, the more likely you are of wanting 
to perform static analysis. It's not because type hints are optional 
that I have some kind of choice about the matter. I may force myself, or 
be forced, to use them. And if that is the case, I would rather prefer 
having a syntax that doesn't clutter my ezxecutable code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unicode question

[random832]

On Tue, Jan 27, 2015, at 12:25, Mark Lawrence wrote:
> People might find this http://bugs.python.org/issue1602 and hence this 
> https://github.com/Drekin/win-unicode-console useful.  The latter is 
> available on pypi.

However, Arabic is one of those scripts that runs up against the real
limitations of the windows console. At least on non-Arabic versions of
Windows, you'll just get a sequence of boxes, and it won't do any
bidirectional processing either. I have no idea what, if anything, it
would do differently on Arabic versions of Windows.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Mario Figueiredo]

In article , 
jpiit...@ling.helsinki.fi says...
> 
> If you mean literally some_predicate, then perhaps this.
> 
> if some_predicate:
>for x in seq:
>   handle(x)
> 

Careful. See Chris Warrick answer for the correct position of the 'if' 
statement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[random832]

On Tue, Jan 27, 2015, at 13:05, Mario Figueiredo wrote:
> In article , 
> jpiit...@ling.helsinki.fi says...
> > 
> > If you mean literally some_predicate, then perhaps this.
> > 
> > if some_predicate:
> >for x in seq:
> >   handle(x)
> > 
> 
> Careful. See Chris Warrick answer for the correct position of the 'if' 
> statement.

I think by "if you mean literally some_predicate" he was taking
some_predicate as a variable [rather than an expression] that does not
change during the loop. That'd be a silly thing to do in the originally
posted code, though, since it'd be easier to do "[] if not
some_predicate else [...]"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Neal Becker]

Jussi Piitulainen wrote:

> Neal Becker writes:
> 
>> Is there a more elegant way to spell this?
>> 
>> for x in [_ for _ in seq if some_predicate]:
> 
> If you mean some_predicate(_), then possibly this.
> 
> for x in filter(some_predicate, seq):
>handle(x)
> 
> If you mean literally some_predicate, then perhaps this.
> 
> if some_predicate:
>for x in seq:
>   handle(x)
> 
> Unless you also have in mind an interesting arrangement where
> some_predicate might change during the loop, like this.
> 
> for x in [_ for _ in seq if some_predicate]:
> ...
> some_predicate = fubar(x)
> ...
> 
> Then I have nothing to say.


To clarify, I meant some_predicate(_), and then ifilter looks like a nice 
solution.

-- 
-- Those who don't understand recursion are doomed to repeat it

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

Re: Is there a more elegant way to spell this?

[Emile van Sebille]

On 1/27/2015 9:49 AM, Rob Gaddi wrote:

Or the somewhat less indenty

for x in seq:
 if not some_predicate: continue
 do_something_to(x)




... or shorter and equally less indenty


for x in seq:
if some_predicate: do_something_to(x)

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

Re: Formatting string with accented characters for printing

[John Ladasky]

Jerry,

I can tell from your code that you are using Python 2.  If you are a new Python 
programmer, and you do not HAVE to use Python 2, use Python 3 instead.

In Python 3, text objects are something called "Unicode" rather than just 
sequences of bytes.  Unicode makes it much easier to handle characters which 
are not part of the English alphabet.
-- 
https://mail.python.org/mailman/listinfo/python-list

An object is an instance (or not)?

[Mario Figueiredo]

This is a follow up from a previous discussion in which it is argued 
that the following code produces the correct error message terminology, 
considering that in Python an object is also an instance.

>>> class Sub:
>>> pass

>>> foo = Sub()
>>> foo.__bases__
[...]
AttributeError: 'Sub' object has no attribute '__bases__'

I'm making this into a new thread, because the particular discussion of 
whether an object is an instance in Python seems more interesting than 
discussing whether that error message should be changed or not.

Here's another example where the terminology keeps indicating that in 
Python an object is an instance:

>>> class Sub:
pass

>>> x = Sub()
>>> x
<__main__.Sub object at 0x02631690>

The problem is that I personally cannot agree with this terminology and 
I would like to hear arguments that could convince me to adopt the 
Python way. But before your replies, here's my argumentation:

An instance IS an object. On that we can agree. After all, everything in 
Python is an object. Even classes are. We can even pass them as function 
arguments:

>>> class Sub:
pass

>>> def show(aClass):
print(type(aClass))

>>> show(Sub)


The problem is that an object isn't always an instance. The word 
instance in OOP has a very formal meaning. In programming languages in 
which the classes aren't fully realized objects, it is ok to speak of 
'instance' and 'object' interchangeably. But even then, sometimes the 
term 'object instance' is preferred, as a way to separate these 
'instances' from other variable instances that may not be created from 
class definitions (e.g. C++ built-in types).

The fact that in Python classes are objects, should not just eliminate 
this distinction. The OOP terminology should exist beyond the language 
implementing it. It facilitates discourse and helps transmiting concepts 
when describing your ideas to another programmer. And because in python, 
classes are of the type 'type' and they exist as fully realized objects, 
is no excuse to make a distinction between them and their own fully 
realized instances. The language implementation details should not exist 
as a way for us to freely reformulate long standing terms.

Because, from my own study of Python, I've came to realize that the 
distinction between objects and instances of objects actually exists. In 
Python, class objects cannot participate in OOP, only their instances. 
This is why I say that even in Python, where a class is an object, an 
object is not always an instance. The language itself forces that 
distinction.

...

I don't think that any of this is reason enough to rewrite error 
messages in Python. Seems unnecessary. What I'm arguing thought is that 
error messages in Python cannot become the source of new terminology. 
The language itself implements a very clear distinction between class 
objects and their instances. And it is thus wrong of us to say that 
Object = Instance. At least from an OOP perspective.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ethan Furman]

On 01/27/2015 12:12 PM, Mario Figueiredo wrote:
>
> Because, from my own study of Python, I've came to realize that the 
> distinction between objects and instances of objects actually exists. In 
> Python, class objects cannot participate in OOP, only their instances. 

I haven't followed the other thread.  Can you give an example of this?  Because 
I have a counter-example ready:  the new
Enum data type, which uses a metaclass to treat the class just like any other 
instance of a normal class:

  list(MyEnum)  # fails on a regular class

  for enum in MyEnum: # fails on a regular class

  MyEnum['EnumName']  # fails on a regular class

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Angelico]

On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo  wrote:
> An optional feature says nothing of its requirements. The requirements
> for PEP 484 are heavy. Not only will they force an update to the
> interpreter, but will also force many users to reformate their function
> headers in order for them to become bareable to the eye. In fact, no
> longer will you look at function definitions like you did before.

What updates are needed to the interpreter?

https://www.python.org/dev/peps/pep-3107/

Already happened, long ago.

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

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 16:12:47 UTC-4, Mario Figueiredo  wrote:
> This is a follow up from a previous discussion in which it is argued 
> that the following code produces the correct error message terminology, 
> considering that in Python an object is also an instance.
> 
> >>> class Sub:
> >>> pass
> 
> >>> foo = Sub()
> >>> foo.__bases__
> [...]
> AttributeError: 'Sub' object has no attribute '__bases__'
> 
> I'm making this into a new thread, because the particular discussion of 
> whether an object is an instance in Python seems more interesting than 
> discussing whether that error message should be changed or not.
> 
> Here's another example where the terminology keeps indicating that in 
> Python an object is an instance:
> 
> >>> class Sub:
>   pass
> 
> >>> x = Sub()
> >>> x
> <__main__.Sub object at 0x02631690>
> 
> The problem is that I personally cannot agree with this terminology and 
> I would like to hear arguments that could convince me to adopt the 
> Python way. But before your replies, here's my argumentation:
> 
> An instance IS an object. On that we can agree. After all, everything in 
> Python is an object. Even classes are. We can even pass them as function 
> arguments:
> 
> >>> class Sub:
>   pass
> 
> >>> def show(aClass):
>   print(type(aClass))
>   
> >>> show(Sub)
> 
> 
> The problem is that an object isn't always an instance. The word 
> instance in OOP has a very formal meaning. In programming languages in 
> which the classes aren't fully realized objects, it is ok to speak of 
> 'instance' and 'object' interchangeably. But even then, sometimes the 
> term 'object instance' is preferred, as a way to separate these 
> 'instances' from other variable instances that may not be created from 
> class definitions (e.g. C++ built-in types).
> 
> The fact that in Python classes are objects, should not just eliminate 
> this distinction. The OOP terminology should exist beyond the language 
> implementing it. It facilitates discourse and helps transmiting concepts 
> when describing your ideas to another programmer. And because in python, 
> classes are of the type 'type' and they exist as fully realized objects, 
> is no excuse to make a distinction between them and their own fully 
> realized instances. The language implementation details should not exist 
> as a way for us to freely reformulate long standing terms.
> 
> Because, from my own study of Python, I've came to realize that the 
> distinction between objects and instances of objects actually exists. In 
> Python, class objects cannot participate in OOP, only their instances. 
> This is why I say that even in Python, where a class is an object, an 
> object is not always an instance. The language itself forces that 
> distinction.
> 
> ...
> 
> I don't think that any of this is reason enough to rewrite error 
> messages in Python. Seems unnecessary. What I'm arguing thought is that 
> error messages in Python cannot become the source of new terminology. 
> The language itself implements a very clear distinction between class 
> objects and their instances. And it is thus wrong of us to say that 
> Object = Instance. At least from an OOP perspective.

You keep writing "an object is not an instance", making statements such as "the 
terminology keeps indicating that in Python an object is an instance" and yet, 
none of the examples you show from Python (tracebacks or repr outputs) include 
the word "instance".   

To phrase it differently: all the examples of output from Python that you show 
use the word "object" and not the word "instance".  Yet **you** claim that 
"Python" states that objects are instances Can you point out at least 
one example where "Python" wrongly use the word instance instead of object?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
ros...@gmail.com says...
> 
> On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo  wrote:
> > An optional feature says nothing of its requirements. The requirements
> > for PEP 484 are heavy. Not only will they force an update to the
> > interpreter, but will also force many users to reformate their function
> > headers in order for them to become bareable to the eye. In fact, no
> > longer will you look at function definitions like you did before.
> 
> What updates are needed to the interpreter?
> 
> https://www.python.org/dev/peps/pep-3107/
> 
> Already happened, long ago.

I wasn't aware the interpreter was already able to parse PEP 484. Thank 
you. Strike that phrase of that paragraph.

But what a royal mess!

Looking at PEP 3107, i'm left wondering: what if I have for instance 
already annotated my functions for parameter marshalling, following the 
syntax expected of that specific library, and now I want to annotate 
them for type hinting for the purposes of static analysis?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Angelico]

On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo  wrote:
> Looking at PEP 3107, i'm left wondering: what if I have for instance
> already annotated my functions for parameter marshalling, following the
> syntax expected of that specific library, and now I want to annotate
> them for type hinting for the purposes of static analysis?

This is the kind of argument that keeps on coming up. Everyone has a
"What if" scenario about function annotations... and almost nobody
actually has a codebase that uses them. It's equivalent to asking:
"What if I already used docstrings to control URL routing, and now I
want to use them for function documentation?". Well, simple. You move
your other-use-of-annotations out to something else (probably a
decorator) before you add type hints. Until that time, you're welcome
to continue using annotations for something other than type hinting;
you just can't do both at once on the same function.

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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article <80a9f882-6b13-45a7-b514-8c47b3a4c...@googlegroups.com>, 
andre.robe...@gmail.com says...
> 
> You keep writing "an object is not an instance", making statements
> such as "the terminology keeps indicating that in Python an object is 
> an instance" and yet, none of the examples you show from Python
> (tracebacks or repr outputs) include the word "instance".   

I think you misread my argument. Look at the first example on my post, 
or follow the discussion on "__bases__ misleading error message" here on 
the newsgroups.

That error message has me start that thread arguing that the error is 
misleading because the Sub object does have the __bases__ attribute. 
It's the Sub instance object that does not have it.

Some of the answers that were given argued that in Python object = 
instance.

> Yet
> **you** claim that "Python" states that objects are instances 

That is no my claim. I said that much. You should probably read my post 
more carefully.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
ros...@gmail.com says...
> 
> On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo  wrote:
> > Looking at PEP 3107, i'm left wondering: what if I have for instance
> > already annotated my functions for parameter marshalling, following the
> > syntax expected of that specific library, and now I want to annotate
> > them for type hinting for the purposes of static analysis?
> 
> This is the kind of argument that keeps on coming up. Everyone has a
> "What if" scenario about function annotations... and almost nobody
> actually has a codebase that uses them. It's equivalent to asking:
> "What if I already used docstrings to control URL routing, and now I
> want to use them for function documentation?". Well, simple. You move
> your other-use-of-annotations out to something else (probably a
> decorator) before you add type hints. Until that time, you're welcome
> to continue using annotations for something other than type hinting;
> you just can't do both at once on the same function.
> 
> ChrisA

I'm sorry Chris. But that's a weak argument and you know it. If I use 
those decorators inside properly formated docstrings, I can do both 
things, and more! And I don't have to  move anything anywhere. 

def func(a, b, c):
"""
This function does something very interesting and returns a surprise
:a: an integer, also known as whole number (lies!)
:b: a float on a string so it can't escape
:c: an unicode string with some bad language

@typehint@ some crazy syntax for static analysis
@marshallib@ more crazy syntax for the marshall lib
@anotherlib@ Whoohoo! a 3rd annotation for another lib
"""

Are you telling me this is not a viable alternative. That somehow we 
should ignore the possibility of potentially different annotations 
having to coexist on a project? C'mon!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Angelico]

On Wed, Jan 28, 2015 at 8:19 AM, Mario Figueiredo  wrote:
> @typehint@ some crazy syntax for static analysis
> @marshallib@ more crazy syntax for the marshall lib
> @anotherlib@ Whoohoo! a 3rd annotation for another lib
> """
>
> Are you telling me this is not a viable alternative. That somehow we
> should ignore the possibility of potentially different annotations
> having to coexist on a project? C'mon!

Sure you can! But this is *itself* a weak argument, unless you
actually have a codebase that uses it. YAGNI comes to mind. When do
you actually need to annotate with multiple styles like this, and
should everyone pay the price (the disconnect from from the function
name) even though this is almost never needed?

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

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 17:06:50 UTC-4, Mario Figueiredo  wrote:
> In article <80a9f882-6b13-45a7-b514-8c47b3a4c...@googlegroups.com>, 
> andre.robe...@gmail.com says...
> > 
> > You keep writing "an object is not an instance", making statements
> > such as "the terminology keeps indicating that in Python an object is 
> > an instance" and yet, none of the examples you show from Python
> > (tracebacks or repr outputs) include the word "instance".   
> 
> I think you misread my argument. Look at the first example on my post, 
> or follow the discussion on "__bases__ misleading error message" here on 
> the newsgroups.


> 
> That error message has me start that thread arguing that the error is 
> misleading because the Sub object does have the __bases__ attribute. 
> It's the Sub instance object that does not have it.
> 

To use the word object to describe an instance is perfectly appropriate. Your 
claims imply the the opposite is happening.

> Some of the answers that were given argued that in Python object = 
> instance.
> 
> > Yet
> > **you** claim that "Python" states that objects are instances 
> 
> That is no my claim. I said that much. You should probably read my post 
> more carefully.

I read your post carefully: not once did I see an output from Python using the 
word "instance".


>From your post:

 Python's output ==
AttributeError: 'Sub' object has no attribute '__bases__' 
=
Python uses the word "object, not "instance".



++ your words +++

Here's another example where the terminology keeps indicating that in 
Python an object is an instance: 
++

==Python's output ===
<__main__.Sub object at 0x02631690> 
===
Python uses the word "object, not "instance", contrary to what you wrote.



+++ your words ++

The problem is that an object isn't always an instance. 
+


 your words 

What I'm arguing thought is that 
error messages in Python cannot become the source of new terminology. 


Not a single output from Python uses the word instance.

It is appropriate to refer to an instance as an object.  It might not be 
appropriate to refer to an object as an instance ... but Python does not do so 
as your explicit examples demonstrate, and contrary to your claim.

A.R.


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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
ros...@gmail.com says...
> 
> Sure you can! But this is *itself* a weak argument, unless you
> actually have a codebase that uses it.

Wait. Are you saying that unless I show you a codebase that requires 
marshalling and static analysis, you will ignore the fact that a 
project, no matter its size, may require more than one annotation type?

In other words, lets suggest function annotations as a restrictive 
feature, instead of a feature that can adapt to more than one use case.

> YAGNI comes to mind. When do
> you actually need to annotate with multiple styles like this, and
> should everyone pay the price (the disconnect from from the function
> name) even though this is almost never needed?

That is your price. My price is seeing my executable code cluttered with 
static fluff. Very pythonesc, I suppose...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

I can now start to understand the criticism of how Python is evolving 
coming from many corners, either long term python educators like Mark 
Lutz.


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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
andre.robe...@gmail.com says...
> 
> It is appropriate to refer to an instance as an object.  It might not 
> be appropriate to refer to an object as an instance ... but Python
> does not do so as your explicit examples demonstrate, and contrary to 
> your claim.

I'll try one more time: It - Is - Not - My - Claim.

It is the claim of a few users in here that replied to that thread.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 17:43:38 UTC-4, Mario Figueiredo  wrote:
> In article , 
> andre.robe...@gmail.com says...
> > 
> > It is appropriate to refer to an instance as an object.  It might not 
> > be appropriate to refer to an object as an instance ... but Python
> > does not do so as your explicit examples demonstrate, and contrary to 
> > your claim.
> 
> I'll try one more time: It - Is - Not - My - Claim.
> 
> It is the claim of a few users in here that replied to that thread.

At the very beginning of the first message I replied to, you wrote:

**This is a follow up from a previous discussion in which it is argued 
that the following code produces the correct error message terminology **

I pointed out to you that the word object WAS used correctly: hence, the 
correct terminology was used in that error message.

You are just wasting people's time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Angelico]

On Wed, Jan 28, 2015 at 8:35 AM, Mario Figueiredo  wrote:
> In other words, lets suggest function annotations as a restrictive
> feature, instead of a feature that can adapt to more than one use case.

PEP 3107 made a feature that can adapt to more than one use case. It's
been years now, and the use-cases originally suggested are the only
ones actually seen in the wild. Apparently nobody has actually come up
with a need for the flexibility.

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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article <9a2cf6ca-2eb8-4a87-9e83-e87d90d5f...@googlegroups.com>, 
andre.robe...@gmail.com says...
> 
> **This is a follow up from a previous discussion in which it is argued 
> that the following code produces the correct error message terminology **
> 
> I pointed out to you that the word object WAS used correctly: hence, the 
> correct terminology was used in that error message.
> 
> You are just wasting people's time.

That is just rude!

I'm still trying to understand what is the problem you are having with 
my post. Have you followed the previous thread? Is there anything you 
are not understanding?

People were saying to me that in Python object = instance. I'm trying to 
argue why I believe it isn't and asking for arguments to convince me 
otherwise.

And that's the best you can do?

Python does imply that an object is an instance, btw. It is why I got 
that answer from more than one person. Or so they say.

By referring to an instance of Sub as "Sub object", there's an implicit 
affirmation that an object is an instance.

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

Re: An object is an instance (or not)?

[Ben Finney]

Mario Figueiredo  writes:

> People were saying to me that in Python object = instance. I'm trying
> to argue why I believe it isn't and asking for arguments to convince
> me otherwise.

In Python:

* Every value is an object.

* Every object is an instance of some class.

* To say “object” is uproblematic for values in Python, because the
  programming term “object” doesn't imply anything about classes.

* To say “instance” implies a specific relationship to some particular
  class; in programming terminology (because in English generally) an
  instance is so called only because it is an instance of some specific
  class.

> By referring to an instance of Sub as "Sub object", there's an
> implicit affirmation that an object is an instance.

Correct. That raises a fourth point:

* In the distant past of Python, some objects were not instances of any
  class; the terminology in the documentation and messages shows some
  confusing legacies from that ancient time.

The phrasing “'Foo' object” is ambiguous in a way that “'Foo' instance”
would not be. I agree with others that changing the message to refer to
“'Foo' instance” would be an improvement.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but I find scratching just makes it worse.” —_Pinky and |
_o__)   The Brain_ |
Ben Finney

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

Re: An object is an instance (or not)?

[Mark Lawrence]

On 27/01/2015 21:58, Mario Figueiredo wrote:

In article <9a2cf6ca-2eb8-4a87-9e83-e87d90d5f...@googlegroups.com>,
andre.robe...@gmail.com says...


**This is a follow up from a previous discussion in which it is argued
that the following code produces the correct error message terminology **

I pointed out to you that the word object WAS used correctly: hence, the 
correct terminology was used in that error message.

You are just wasting people's time.


That is just rude!

I'm still trying to understand what is the problem you are having with
my post. Have you followed the previous thread? Is there anything you
are not understanding?

People were saying to me that in Python object = instance. I'm trying to
argue why I believe it isn't and asking for arguments to convince me
otherwise.

And that's the best you can do?

Python does imply that an object is an instance, btw. It is why I got
that answer from more than one person. Or so they say.

By referring to an instance of Sub as "Sub object", there's an implicit
affirmation that an object is an instance.

Bye.



Mario and Andre, when you have to write code to meet the deadline to get 
the stage payment, does either of your bosses really care whether or not 
you are dealing with an object, an instance, or a piece of dead meat 
dropped by the neighbour's cat?


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

Mark Lawrence

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

Re: An object is an instance (or not)?

[Ned Batchelder]

On 1/27/15 3:12 PM, Mario Figueiredo wrote:

This is a follow up from a previous discussion in which it is argued
that the following code produces the correct error message terminology,
considering that in Python an object is also an instance.


I don't know what the difference is between "object" and "instance".  An 
object is an instance of a class.  The two words are interchangeable as 
far as I know.



An instance IS an object. On that we can agree. After all, everything in
Python is an object. Even classes are. We can even pass them as function
arguments:

 >>> class Sub:
pass

 >>> def show(aClass):
print(type(aClass))

 >>> show(Sub)
 

The problem is that an object isn't always an instance. The word
instance in OOP has a very formal meaning.


A common mistake is to believe that "OOP" is a well-defined term.  It's 
not it's a collection of ideas that are expressed slightly differently 
in each language.



In programming languages in
which the classes aren't fully realized objects, it is ok to speak of
'instance' and 'object' interchangeably.


I don't know what a "not fully realized object" is.


But even then, sometimes the
term 'object instance' is preferred, as a way to separate these
'instances' from other variable instances that may not be created from
class definitions (e.g. C++ built-in types).

The fact that in Python classes are objects, should not just eliminate
this distinction. The OOP terminology should exist beyond the language
implementing it. It facilitates discourse and helps transmiting concepts
when describing your ideas to another programmer. And because in python,
classes are of the type 'type' and they exist as fully realized objects,
is no excuse to make a distinction between them and their own fully
realized instances. The language implementation details should not exist
as a way for us to freely reformulate long standing terms.

Because, from my own study of Python, I've came to realize that the
distinction between objects and instances of objects actually exists. In
Python, class objects cannot participate in OOP, only their instances.


What does "participate in OOP" mean?


This is why I say that even in Python, where a class is an object, an
object is not always an instance. The language itself forces that
distinction.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: Python simple Code

[Salem Alqahtani]

On Saturday, January 24, 2015 at 7:16:27 PM UTC-5, Salem Alqahtani wrote:
> Hi Guys,
> 
> I just joined the group and I hope that I can help and be active.
> 
> I have a question about python. I wrote a code on python 2.7 and I want to 
> choose from the list of names that I provide n!. I execute the code but the 
> result or output is the numbers. I want the people names are the result.
> 
> 
> Sincerely
> 
> import sys
> import array
> a=['salem','Ali','sultan']
> m = len(a)
> def Factorials(m):
> if m == 0:
> return 1
> else:
> print m
> return m * Factorials(m-1)
> def output():
> print a
> def main():
> print Factorials(m)
> output()
> main()

Hi Guys,

I appreciate your answers and the output that I am expected from my simple code 
is the following:

['salem','Ali','sultan']
['salem','sultan','Ali']
['Ali','sultan','salem']
['Ali','salem','sultan']
['sultan','Ali','salem']
['sultan','salem','sultan']

the 3 * 2 * 1 is 6 but I do not looking for this output.  

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

Re: An object is an instance (or not)?

[Ben Finney]

Ned Batchelder  writes:

> On 1/27/15 3:12 PM, Mario Figueiredo wrote:
> > This is a follow up from a previous discussion in which it is argued
> > that the following code produces the correct error message terminology,
> > considering that in Python an object is also an instance.
>
> I don't know what the difference is between "object" and "instance".
> An object is an instance of a class.  The two words are
> interchangeable as far as I know.

Not in English grammar, IMO. To say “foo is an instance” implies the
sentence isn't finished; the term “instance” only makes sense in the
context of a relationship to some class. To say “foo is an object”
doesn't have that implication.

> A common mistake is to believe that "OOP" is a well-defined term.
> It's not it's a collection of ideas that are expressed slightly
> differently in each language.

Right. The common meaning of “object” shared by all OOP systems is
surprisingly small.

Many OOP systems do not use classes (e.g. JavaScript) and are no less
object-oriented for that. In such a system it would be true to say “foo
is an object, but is not an instance of anything”.

> > Because, from my own study of Python, I've came to realize that the
> > distinction between objects and instances of objects actually
> > exists. In Python, class objects cannot participate in OOP, only
> > their instances.
>
> What does "participate in OOP" mean?

To the extent I understand (and I'm confused on what that might mean as
you are), I think it's plainly false.

In Python, every class is an object. Every class has the full range of
behaviour that we expect of objects. A class just has the additional
feature that it can be instantiated.

> > This is why I say that even in Python, where a class is an object,
> > an object is not always an instance. The language itself forces that
> > distinction.

You have not, to my knowledge, shown any object (in Python 2.2 or later)
which is not an instance of some class. Python objects are always an
instance of some specific class.

-- 
 \ “Books and opinions, no matter from whom they came, if they are |
  `\ in opposition to human rights, are nothing but dead letters.” |
_o__)  —Ernestine Rose |
Ben Finney

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

Re: An object is an instance (or not)?

[Chris Angelico]

On Wed, Jan 28, 2015 at 10:22 AM, Ned Batchelder  wrote:
> I don't know what the difference is between "object" and "instance".  An
> object is an instance of a class.  The two words are interchangeable as far
> as I know.

My understanding is that "instance" is meaningless unless followed by
"of". That is to say, 123.45 is an object, and it is an instance *of*
the 'float' class. Everything in Python is an instance *of something*,
so in a sense, you can say that everything is an instance, but that's
like saying that everything has a color. Sure it does, but you need to
be more specific.

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

Re: Python simple Code

[Ian Kelly]

On Tue, Jan 27, 2015 at 4:22 PM, Salem Alqahtani  wrote:
> I appreciate your answers and the output that I am expected from my simple 
> code is the following:
>
> ['salem','Ali','sultan']
> ['salem','sultan','Ali']
> ['Ali','sultan','salem']
> ['Ali','salem','sultan']
> ['sultan','Ali','salem']
> ['sultan','salem','sultan']
>
> the 3 * 2 * 1 is 6 but I do not looking for this output.

>>> from itertools import permutations
>>> a = ['salem', 'Ali', 'sultan']
>>> for p in permutations(a):
...   print(list(p))
...
['salem', 'Ali', 'sultan']
['salem', 'sultan', 'Ali']
['Ali', 'salem', 'sultan']
['Ali', 'sultan', 'salem']
['sultan', 'salem', 'Ali']
['sultan', 'Ali', 'salem']
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
n...@nedbatchelder.com says...
> 
> A common mistake is to believe that "OOP" is a well-defined term.  It's 
> not it's a collection of ideas that are expressed slightly differently 
> in each language.

A common mistake is thinking just because OOP has different 
implementations, it doesn't have a cohesive set of well described rules 
and its own well defined terminology.

> I don't know what a "not fully realized object" is.

A fully realized object, in an object oriented paradigm, is an object 
containing or pointing to data and the methods to act on that data. It's 
an instance of a class.

A *not* fully realized object is possible in Python, since Classes are 
first-class objects, despite not being able to participate in OOP.

> 
> What does "participate in OOP" mean?

Means the object is capable of participating in inheritance and/or 
polymorphism. An instance of an object is capable of doing so, per its 
class definitions. Whereas a Python class object is not.

>>> class Master:
def func(self):
pass

>>> class Sub(Master):
pass

>>> Sub.func()
TypeError: func() missing 1 required positional argument: 'self'

But somehow I think you knew the answer to all these questions and were 
instead being snarky.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
ben+pyt...@benfinney.id.au says...
> > > This is why I say that even in Python, where a class is an object,
> > > an object is not always an instance. The language itself forces that
> > > distinction.
> 
> You have not, to my knowledge, shown any object (in Python 2.2 or later)
> which is not an instance of some class. Python objects are always an
> instance of some specific class.

It is true that a class object is an instance of 'type'. But this is a 
special type (can't avoid the pun). A class object is not an instance of 
the type it implements. That is what I mean by an object that isn't an 
instance.

In other words, the object know as "Sub class" is not an instance 
object. True, it is an instance of the object 'type'.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Grant Edwards]

On 2015-01-27, Ned Batchelder  wrote:
> On 1/27/15 3:12 PM, Mario Figueiredo wrote:
>> This is a follow up from a previous discussion in which it is argued
>> that the following code produces the correct error message terminology,
>> considering that in Python an object is also an instance.
>
> I don't know what the difference is between "object" and "instance".  An 
> object is an instance of a class.  The two words are interchangeable as 
> far as I know.

They are interchangable in recent versions of Python.

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

Re: An object is an instance (or not)?

[Chris Angelico]

On Wed, Jan 28, 2015 at 11:17 AM, Mario Figueiredo  wrote:
> Means the object is capable of participating in inheritance and/or
> polymorphism. An instance of an object is capable of doing so, per its
> class definitions. Whereas a Python class object is not.
>
> >>> class Master:
> def func(self):
> pass
>
> >>> class Sub(Master):
> pass
>
> >>> Sub.func()
> TypeError: func() missing 1 required positional argument: 'self'
>
> But somehow I think you knew the answer to all these questions and were
> instead being snarky.

I have no idea what you're proving here. You just showed that the
class has a function attached to it, and you didn't provide enough
arguments to it. And types have their own set of attributes and
methods:

>>> dir(type)
['__abstractmethods__', '__base__', '__bases__', '__basicsize__',
'__call__', '__class__', '__delattr__', '__dict__', '__dictoffset__',
'__dir__', '__doc__', '__eq__', '__flags__', '__format__', '__ge__',
'__getattribute__', '__gt__', '__hash__', '__init__',
'__instancecheck__', '__itemsize__', '__le__', '__lt__', '__module__',
'__mro__', '__name__', '__ne__', '__new__', '__prepare__',
'__qualname__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasscheck__',
'__subclasses__', '__subclasshook__', '__text_signature__',
'__weakrefoffset__', 'mro']

Most of those are inherited from object, but some aren't.

What are you demonstrating?

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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
ros...@gmail.com says...
> 
> On Wed, Jan 28, 2015 at 10:22 AM, Ned Batchelder  
> wrote:
> > I don't know what the difference is between "object" and "instance".  An
> > object is an instance of a class.  The two words are interchangeable as far
> > as I know.
> 
> My understanding is that "instance" is meaningless unless followed by
> "of". That is to say, 123.45 is an object, and it is an instance *of*
> the 'float' class. Everything in Python is an instance *of something*,
> so in a sense, you can say that everything is an instance, but that's
> like saying that everything has a color. Sure it does, but you need to
> be more specific.
> 

In programming languages in which class definitions aren't first-class 
objects, the terms are in fact used interchangeably. And rightly so, 
because an object is in fact always an instance of some class.

Python and a few other languages implement class definitions as first-
class objects. In this case, the distinction between an object and an 
instance is actually an implementation detail and comes with its own 
semantics. This is why I object to the notion that in Python object = 
instance.

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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
ros...@gmail.com says...
> 
> On Wed, Jan 28, 2015 at 11:17 AM, Mario Figueiredo  wrote:
> > Means the object is capable of participating in inheritance and/or
> > polymorphism. An instance of an object is capable of doing so, per its
> > class definitions. Whereas a Python class object is not.
> >
> > >>> class Master:
> > def func(self):
> > pass
> >
> > >>> class Sub(Master):
> > pass
> >
> > >>> Sub.func()
> > TypeError: func() missing 1 required positional argument: 'self'
> >
> I have no idea what you're proving here. You just showed that the
> class has a function attached to it, and you didn't provide enough
> arguments to it. And types have their own set of attributes and
> methods:
> 

I admit it was a contrived example. I couldn't think of a way to 
demonstrate that a class object does not participate in its own 
inheritance rules. Only instances of it can.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
breamore...@yahoo.co.uk says...
> 
> Mario and Andre, when you have to write code to meet the deadline to get 
> the stage payment, does either of your bosses really care whether or not 
> you are dealing with an object, an instance, or a piece of dead meat 
> dropped by the neighbour's cat?

That is valuable input. You don't care how a type or an instance of a 
type differ. Should be intersting to ask you to make a Cat object. I 
wonder if you are not going to ask if they mean a class or an instance 
of that class.

Anyways, more to the point, this is simply a debate on language and how 
to express Python concepts. If that bothers you, I'll take note.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Steven D'Aprano]

Neal Becker wrote:

> Is there a more elegant way to spell this?
> 
> for x in [_ for _ in seq if some_predicate]:

Don't use _ as the loop variable here.

There are three common conventions for _ and this is none of them:


(1) n the interactive interpreter _ is used for the result of the last
expression:

py> 1+2
3
py> _ * 2
6

(2) In locale-aware applications, _ is apparently used as a function for
localising text into the user's native language.

(3) _ is also commonly used as a "don't care" variable name:

a, _, b, _ = get_four_items()  # but I only care about two of them


So in a loop, you would only use _ as the loop variable when you don't use
the loop variable, e.g.:

[random.random() for _ in range(10)]


Of course, a convention is just a convention, not a law, you can ignore such
conventions if you insist. But conventions make it easier and quicker to
understand code, not just for others, but for yourself as well.


-- 
Steven

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

Re: An object is an instance (or not)?

[Ben Finney]

Mario Figueiredo  writes:

> It is true that a class object is an instance of 'type'. But this is a
> special type (can't avoid the pun).

Nevertheless it is a class, and can do everything that classes do.

And every class is an object, and can do everything that objects do.

You seem to agree with those, so please stop claiming that classes are
not objects. Python classes are always objects, and always have been.

> A class object is not an instance of the type it implements.

You keep introducing hurdles that are irrelevant. Yes, a class is not an
instance of itself. That doesn't impact the fact a class is an object.

> That is what I mean by an object that isn't an instance.

That's incoherent. It's an instance of a class, and simultaneously is
not an instance?

> In other words, the object know as "Sub class" is not an instance 
> object. True, it is an instance of the object 'type'.

You've tied yourself in knots with concepts that are not coherent, and
even if they were do not appear to be relevant to Python.

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney

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

Re: Python is DOOMED! Again!

[Steven D'Aprano]

random...@fastmail.us wrote:

> On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote:
>> random...@fastmail.us wrote:
>> - lexical analysis has to look for twice as many files (it has to
>>   hit the hard drive for a stub file before looking at the source),
>>   and we know from importing that file system access is a
>>   significant and expensive part of the process.
> 
> The idea is that the type hinting files would not participate in
> execution at all, only static analysis, so the interpreter doesn't need
> to look for these things at all, it only needs to ignore them.

Yes, but the *type-checker* needs to look for all those files, which slows
the type-checker down.

My estimate of time savings, plucked completely from thin air, is that
type-checkers will save around 5% time by not using a separate stub file.
(Anyone actually using MyPy care to measure it?)

Of course, that will differ according to circumstances: a stub file on a
slow CD/DVD media mounted over the network will be much more expensive than
a stub file on a RAM disk or SSD drive.

Regardless of exactly how much more expensive it is, two sets of file I/O by
definition will be more expensive than one set of file I/O.

But really, this is the minor point against header files. The icing on the
cake, not the cake itself. The big reason for avoiding them is dependency
management and the splitting of information about a single thing into two
files.


-- 
Steven

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

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article , 
ben+pyt...@benfinney.id.au says...
> 
> Mario Figueiredo  writes:
> 
> > It is true that a class object is an instance of 'type'. But this is a
> > special type (can't avoid the pun).
> 
> Nevertheless it is a class, and can do everything that classes do.
> 
> And every class is an object, and can do everything that objects do.
> 
> You seem to agree with those, so please stop claiming that classes are
> not objects. Python classes are always objects, and always have been.
> 
> > A class object is not an instance of the type it implements.
> 
> You keep introducing hurdles that are irrelevant. Yes, a class is not an
> instance of itself. That doesn't impact the fact a class is an object.
> 
> > That is what I mean by an object that isn't an instance.
> 
> That's incoherent. It's an instance of a class, and simultaneously is
> not an instance?
> 
> > In other words, the object know as "Sub class" is not an instance 
> > object. True, it is an instance of the object 'type'.
> 
> You've tied yourself in knots with concepts that are not coherent, and
> even if they were do not appear to be relevant to Python.

Very well. I'm failing at putting my point across. I will not discuss 
this further.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Mario Figueiredo]

In article <54c8339f$0$13008$c3e8da3$54964...@news.astraweb.com>, 
steve+comp.lang.pyt...@pearwood.info says...
> (3) _ is also commonly used as a "don't care" variable name:
> 
> a, _, b, _ = get_four_items()  # but I only care about two of them
> 

According to the following link, it is actually a double underscore:
http://docs.python-guide.org/en/latest/writing/style/#idioms
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Ben Finney]

Mario Figueiredo  writes:

> In article <54c8339f$0$13008$c3e8da3$54964...@news.astraweb.com>, 
> steve+comp.lang.pyt...@pearwood.info says...
> > (3) _ is also commonly used as a "don't care" variable name:
> > 
> > a, _, b, _ = get_four_items()  # but I only care about two of them
> > 
>
> According to the following link, it is actually a double underscore:
> http://docs.python-guide.org/en/latest/writing/style/#idioms

More accurately (and as acknowledged in that guide), a single underscore
*is* a common name for a “don't care” name, but is better avoided for
that purpose because it's also commonly used for other purposes.

In other words: That guide is correct in its admonition, but that
doesn't challenge what Steven said about common usage.

-- 
 \   “My business is to teach my aspirations to conform themselves |
  `\  to fact, not to try and make facts harmonise with my |
_o__)   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

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

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> Static analysis cannot and should not clutter executable code.

(1) It isn't clutter. The human reader uses that information as well as the
compiler, interpreter, type-checker, IDE, text editor, correctness tester,
etc.

(2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go,
Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens
(hundreds?) of other languages disagree with you.



> Let [type-hints] reside in comments, docstrings, external files, whatever.

Didn't you criticise the use of type-hints in comments earlier? Or am I
confusing you with somebody else?



> I'm actually baffled that PEP 484 came into existence, let alone it 
> having any kind of supporter. Here we have a syntax that even requires 
> changes to the interpreter so it can safely ignore all the type hinting 
> clutter that is going to be added by anyone wanting to perform static 
> analysis.

That *absolutely is not true*. I don't know where you get this from.

Python 3 has supported function annotations for over five years now. The
only change required with PEP 484 is to give those annotations a standard
meaning and encourage people to use them for type-checking instead of
whatever other uses they have or haven't (mostly haven't) thought of.



> The requirements 
> for PEP 484 are heavy. Not only will they force an update to the 
> interpreter, but will also force many users to reformate their function 
> headers in order for them to become bareable to the eye. In fact, no 
> longer will you look at function definitions like you did before.

Again, this is wrong. PEP 484 requires *no* update to the interpreter. It
adds a single library file to the standard library, but use of that is
optional. It requires *nobody* to rewrite or reformate their function
headers. The only people who will do so are those who want to run
type-checkers which support type-hints.



-- 
Steven

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

Re: Python simple Code

[Salem Alqahtani]

On Tuesday, January 27, 2015 at 6:51:10 PM UTC-5, Ian wrote:
> On Tue, Jan 27, 2015 at 4:22 PM, Salem Alqahtani  wrote:
> > I appreciate your answers and the output that I am expected from my simple 
> > code is the following:
> >
> > ['salem','Ali','sultan']
> > ['salem','sultan','Ali']
> > ['Ali','sultan','salem']
> > ['Ali','salem','sultan']
> > ['sultan','Ali','salem']
> > ['sultan','salem','sultan']
> >
> > the 3 * 2 * 1 is 6 but I do not looking for this output.
> 
> >>> from itertools import permutations
> >>> a = ['salem', 'Ali', 'sultan']
> >>> for p in permutations(a):
> ...   print(list(p))
> ...
> ['salem', 'Ali', 'sultan']
> ['salem', 'sultan', 'Ali']
> ['Ali', 'salem', 'sultan']
> ['Ali', 'sultan', 'salem']
> ['sultan', 'salem', 'Ali']
> ['sultan', 'Ali', 'salem']

Thank you so much
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> Looking at PEP 3107, i'm left wondering: what if I have for instance
> already annotated my functions for parameter marshalling, following the
> syntax expected of that specific library, and now I want to annotate
> them for type hinting for the purposes of static analysis?

You cannot simultaneously follow two competing standards.

If you have a library that expects annotations to represent (let's say)
parameter marshalling, and another library that expects annotations to
represent documentation, and a third library that expects annotations to
represent hyperlinks to external resources, and a fourth that expects them
to be used for range checking, would you expect to be able to use all four
competing and incompatible uses of annotations in the same function at the
same time? Or even any two such libraries at the same time?

Of course not. At best, each library will ignore annotations that it doesn't
understand. Possibly they will print warnings, or raise exceptions, and
force you to choose between them. At worst, the libraries will misinterpret
the annotation and do the wrong thing, with consequences ranging from
annoying to disastrous. But unless all four libraries are designed from the
start to cooperate, you cannot expect them to cooperate.

Why should type hints be held to a higher (and impossible) standard?

If you use annotations for some other purposes, your choices post-PEP 484
will become:

- Do absolutely nothing different, and your annotations will continue to
work exactly as they currently do. You're not currently running a
type-checker which expects annotations to be type-hints, so you merely
continue *not running* such a type-checker.

Or, if you decide that you do want to run a type-checker:

- Find a type-checker that doesn't use annotations, and use whatever rules
it uses. I believe some linters (obiwan comes to mind?) may use type hints
in docstrings to do simple type checking. Find such a tool, or write your
own, and use it.

- Find a type-checker which can cooperatively interoperate with your
existing use of annotations, if such a thing exists. Feel free to write one
if you wish, or pony up the money to pay somebody else to do so.

- Use a stub file, and a type-checker which will ignore the annotations and
use the stub file instead.

- Give up on your dream of lexical analysis of Python. You can't have
everything, and your Python experience will be just like 2014 all over
again.

- Give up on your current use of annotations, and replace them with
type-hints.

- Change to some other language that does everything you want, and re-write
your entire application in this new language.

- Stamp your feet and hold your breath until you collapse and see if that
helps. (It probably won't, but my two year old nephew[1] thinks it does.)

PEP 484 gives you many choices, starting with "do absolutely nothing, and
absolutely nothing will change".





[1] Actually, that's a gross slander. For somebody right in the middle of
the terrible twos, he's relatively sweet natured and well behaved.

-- 
Steven

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

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 1:42:47 AM UTC+5:30, Mario Figueiredo wrote:
> This is a follow up from a previous discussion in which it is argued 
> that the following code produces the correct error message terminology, 
> considering that in Python an object is also an instance.
> 
> >>> class Sub:
> >>> pass
> 
> >>> foo = Sub()
> >>> foo.__bases__
> [...]
> AttributeError: 'Sub' object has no attribute '__bases__'
> 
> I'm making this into a new thread, because the particular discussion of 
> whether an object is an instance in Python seems more interesting than 
> discussing whether that error message should be changed or not.
> 
> Here's another example where the terminology keeps indicating that in 
> Python an object is an instance:
> 
> >>> class Sub:
>   pass
> 
> >>> x = Sub()
> >>> x
> <__main__.Sub object at 0x02631690>
> 
> The problem is that I personally cannot agree with this terminology and 
> I would like to hear arguments that could convince me to adopt the 
> Python way. But before your replies, here's my argumentation:
> 
> An instance IS an object. On that we can agree. After all, everything in 
> Python is an object. Even classes are. We can even pass them as function 
> arguments:
> 
> >>> class Sub:
>   pass
> 
> >>> def show(aClass):
>   print(type(aClass))
>   
> >>> show(Sub)
> 
> 
> The problem is that an object isn't always an instance. The word 
> instance in OOP has a very formal meaning. In programming languages in 
> which the classes aren't fully realized objects, it is ok to speak of 
> 'instance' and 'object' interchangeably. But even then, sometimes the 
> term 'object instance' is preferred, as a way to separate these 
> 'instances' from other variable instances that may not be created from 
> class definitions (e.g. C++ built-in types).
> 
> The fact that in Python classes are objects, should not just eliminate 
> this distinction. The OOP terminology should exist beyond the language 
> implementing it. It facilitates discourse and helps transmiting concepts 
> when describing your ideas to another programmer. And because in python, 
> classes are of the type 'type' and they exist as fully realized objects, 
> is no excuse to make a distinction between them and their own fully 
> realized instances. The language implementation details should not exist 
> as a way for us to freely reformulate long standing terms.
> 
> Because, from my own study of Python, I've came to realize that the 
> distinction between objects and instances of objects actually exists. In 
> Python, class objects cannot participate in OOP, only their instances. 
> This is why I say that even in Python, where a class is an object, an 
> object is not always an instance. The language itself forces that 
> distinction.
> 
> ...
> 
> I don't think that any of this is reason enough to rewrite error 
> messages in Python. Seems unnecessary. What I'm arguing thought is that 
> error messages in Python cannot become the source of new terminology. 
> The language itself implements a very clear distinction between class 
> objects and their instances. And it is thus wrong of us to say that 
> Object = Instance. At least from an OOP perspective.

The issue (as I see it) is primarily with English - in particular the word 
'is', technically called copula:
https://en.wikipedia.org/wiki/Copula_%28linguistics%29

Is is(!) used in 3 ways that can get mutually incompatible:
Predication: The sky is blue
Identity: Two plus three is five [Notice how you've used '=' above]
Belonging: (OOP isa relation): Cat is a mammal

Some people have found this (mis|over)use of 'is' so problematic that they have 
suggested to doctor English to not use is as far as possible:
https://en.wikipedia.org/wiki/E-Prime
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ian Kelly]

On Tue, Jan 27, 2015 at 5:17 PM, Mario Figueiredo  wrote:
> In article ,
> n...@nedbatchelder.com says...
>> What does "participate in OOP" mean?
>
> Means the object is capable of participating in inheritance and/or
> polymorphism. An instance of an object is capable of doing so, per its
> class definitions. Whereas a Python class object is not.

Python class objects are capable of doing both these things.

> >>> class Master:
> def func(self):
> pass
>
> >>> class Sub(Master):
> pass
>
> >>> Sub.func()
> TypeError: func() missing 1 required positional argument: 'self'

You get the same result by calling Master.func(), so I don't see how
this is a counter-example. Anyway, here is how class objects
participate in inheritance:

class BaseMetaClass(type):
def func(cls):
return 42

class DerivedMetaClass(BaseMetaClass):
pass

class DerivedClass(metaclass=DerivedMetaClass):
pass

>>> isinstance(DerivedClass, BaseMetaClass)
True
>>> print(DerivedClass.func())
42

Note that this is exactly the same way that non-class objects
participate in inheritance. Instances don't simply inherit from other
instances. Rather, the class of the instance inherits from other
classes and provides methods to the instances. And that's what happens
here: the class's meta class inherits from another, and the method it
defines is callable on the instance.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more elegant way to spell this?

[Steven D'Aprano]

Mario Figueiredo wrote:

> In article <54c8339f$0$13008$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>> (3) _ is also commonly used as a "don't care" variable name:
>> 
>> a, _, b, _ = get_four_items()  # but I only care about two of them
>> 
> 
> According to the following link, it is actually a double underscore:
> http://docs.python-guide.org/en/latest/writing/style/#idioms

That's third-party documentation, not official, and I strongly disagree with
a couple of those recommendations. But this specific one seems reasonable
enough.


-- 
Steven

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

Re: An object is an instance (or not)?

[Ned Batchelder]

On 1/27/15 7:17 PM, Mario Figueiredo wrote:

In article ,
n...@nedbatchelder.com says...


A common mistake is to believe that "OOP" is a well-defined term.  It's
not it's a collection of ideas that are expressed slightly differently
in each language.


A common mistake is thinking just because OOP has different
implementations, it doesn't have a cohesive set of well described rules
and its own well defined terminology.


I know you think that it has well described rules and terminology.  But 
take a look at this discussion, and maybe realize that the terms are not 
as well-defined, or certainly not as widely accepted as you think.


Do you have a reference that defines these terms?




I don't know what a "not fully realized object" is.


A fully realized object, in an object oriented paradigm, is an object
containing or pointing to data and the methods to act on that data. It's
an instance of a class.

A *not* fully realized object is possible in Python, since Classes are
first-class objects, despite not being able to participate in OOP.


What does "participate in OOP" mean?


Means the object is capable of participating in inheritance and/or
polymorphism. An instance of an object is capable of doing so, per its
class definitions. Whereas a Python class object is not.

 >>> class Master:
 def func(self):
 pass

 >>> class Sub(Master):
 pass

 >>> Sub.func()
 TypeError: func() missing 1 required positional argument: 'self'




But somehow I think you knew the answer to all these questions and were
instead being snarky.


I am not being snarky, I'm trying to understand where our mutual 
incomprehension lies.



--
Ned Batchelder, http://nedbatchelder.com

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

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 7:55:12 AM UTC+5:30, Ned Batchelder wrote:
> On 1/27/15 7:17 PM, Mario Figueiredo wrote:
> > Ned Batchelder says...
> >>
> >> A common mistake is to believe that "OOP" is a well-defined term.  It's
> >> not it's a collection of ideas that are expressed slightly differently
> >> in each language.
> >
> > A common mistake is thinking just because OOP has different
> > implementations, it doesn't have a cohesive set of well described rules
> > and its own well defined terminology.
> 
> I know you think that it has well described rules and terminology.  But 
> take a look at this discussion, and maybe realize that the terms are not 
> as well-defined, or certainly not as widely accepted as you think.

I'd go a step or two further than that.

Here's a discussion almost isomorphic [including Ned's futile attempts at
inducing sanity] to this one from a few years ago
https://groups.google.com/d/msg/comp.lang.python/y6mnzDeEsRU/Wvpo4mJ-a2gJ
[And others by that same OP - Mark Janssen - zipher]¹

And there's the recent one (2 because of thread breaking) on
<>

To me all these suggest that OOP as a philosophy pickles the brain.
And violently passionate adherence to the philosophy conduces to madness.

[Reminded of a quote I saw on the scheme mailing list:
OOP is the phlogiston theory of CS
]


¹ To those who suffer violent allergic reactions on seeing ...groups.google... 
the numbering of the official archive is so fluid that even
google (search engine!) is getting confused and pointing to broken links
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python simple Code

[Denis McMahon]

On Tue, 27 Jan 2015 15:22:01 -0800, Salem Alqahtani wrote:

> I appreciate your answers and the output that I am expected from my
> simple code is the following:
> 
> ['salem','Ali','sultan']
> ['salem','sultan','Ali']
> ['Ali','sultan','salem']
> ['Ali','salem','sultan']
> ['sultan','Ali','salem']
> ['sultan','salem','sultan']

A long way to do this is as follows (you've already been shown the short 
way using permutations)

words = ['salem','Ali','sultan']

for a in words:
for b in words:
 if b != a:
  for c in words:
  if c != a:
  if c != b:
  print [a, b, c]

Not quite so long:

words = ['salem','Ali','sultan']

for a in words:
for b in [x for x in words if x != a]:
for c in [x for x in words if x != a and x != b]:
print [a, b, c]

Observe that neither of these scale as elegantly as the permutations 
example already given.

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[alex23]

On 28/01/2015 10:35 AM, Mario Figueiredo wrote:

I admit it was a contrived example. I couldn't think of a way to
demonstrate that a class object does not participate in its own
inheritance rules. Only instances of it can.


A class object isn't an instance of itself, it's an instance of the 
Class (to be extact, 'type') class. Method dispatching will also 
traverse the base classes when refering to the class object, too:


>>> class Master:
... @classmethod
... def func(cls):
... return cls
...
>>> class Sub(Master):
... pass
...
>>> type(Sub)

>>> Sub.func()




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

Re: An object is an instance (or not)?

[alex23]

On 28/01/2015 10:24 AM, Mario Figueiredo wrote:

In other words, the object know as "Sub class" is not an instance
object. True, it is an instance of the object 'type'.


>>> class Foo:
... pass
...
>>> isinstance(Foo, type)
True
>>> isinstance(Foo, object)
True

A class is an object that is an instance of the class type. I'm still 
failing to see what distinction you're trying to make here.

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

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 10:18:07 AM UTC+5:30, alex23 wrote:
> On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
> > In other words, the object know as "Sub class" is not an instance
> > object. True, it is an instance of the object 'type'.
> 
>  >>> class Foo:
>  ... pass
>  ...
>  >>> isinstance(Foo, type)
>  True
>  >>> isinstance(Foo, object)
>  True
> 
> A class is an object that is an instance of the class type. I'm still 
> failing to see what distinction you're trying to make here.

Confusion is not disallowed is it ;-)
Maybe some diagrams will help. Something like
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.631&rep=rep1&type=pdf
pic on page 7 particularly the distinction between the arrows and the dotted 
arrows
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Marko Rauhamaa]

Mario Figueiredo :

> That is valuable input. You don't care how a type or an instance of a
> type differ. Should be intersting to ask you to make a Cat object. I
> wonder if you are not going to ask if they mean a class or an instance
> of that class.
>
> Anyways, more to the point, this is simply a debate on language and how 
> to express Python concepts. If that bothers you, I'll take note.

Python itself has answers to your questions:

   >>> isinstance(3, int)
   True
   >>> isinstance("3", int)
   False
   >>> isinstance(int, type)
   True
   >>> isinstance(type, int)
   False
   >>> isinstance(type, type)
   True
   >>> isinstance(3, type)
   False
   >>> isinstance(int, 3)
   Traceback (most recent call last):
 File "", line 1, in 
   TypeError: isinstance() arg 2 must be a type or tuple of types
   >>> isinstance(3, object)
   True
   >>> isinstance("3", object)
   True
   >>> isinstance(int, object)
   True
   >>> isinstance(type, object)
   True
   >>> isinstance(object, object)
   True


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

Re: An object is an instance (or not)?

[random832]

On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote:
> That error message has me start that thread arguing that the error is 
> misleading because the Sub object does have the __bases__ attribute. 
> It's the Sub instance object that does not have it.

What do you think "Sub object" means?

Sub itself is not a Sub object, it is a type object. "instance" is
implicit in the phrase "foo object".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Devin Jeanpierre]

On Tue, Jan 27, 2015 at 9:37 PM,   wrote:
> On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote:
>> That error message has me start that thread arguing that the error is
>> misleading because the Sub object does have the __bases__ attribute.
>> It's the Sub instance object that does not have it.
>
> What do you think "Sub object" means?
>
> Sub itself is not a Sub object, it is a type object. "instance" is
> implicit in the phrase "foo object".

Yes. Unfortunately, it's still not really completely clear. "Sub
instance" would avoid this confusion for everyone.

I think the only reason to avoid "instance" in the past would have
been the old-style object confusion, as Ben Finney pointed out. (BTW I
agree with literally every single thing he said in this thread, it's
really amazing.)

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

Re: An object is an instance (or not)?

[random832]

On Tue, Jan 27, 2015, at 23:47, alex23 wrote:
> On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
> > In other words, the object know as "Sub class" is not an instance
> > object. True, it is an instance of the object 'type'.
> 
>  >>> class Foo:
>  ... pass
>  ...
>  >>> isinstance(Foo, type)
>  True
>  >>> isinstance(Foo, object)
>  True
> 
> A class is an object that is an instance of the class type. I'm still 
> failing to see what distinction you're trying to make here.

I think his objection is to the use of the phrase "'Sub' object" to
refer only to instances of the Sub type, when 'Sub' is the name of the
type object itself and therefore (he thinks) "'Sub' object" should refer
to it instead. (I can only assume he wants "'x' object" for x = Sub().)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 10:55:32 AM UTC+5:30, Marko Rauhamaa wrote:
> Python itself has answers to your questions:
> 
>>>> isinstance(3, int)
>True
>>>> isinstance("3", int)
>False
>>>> isinstance(int, type)
>True
>>>> isinstance(type, int)
>False
>>>> isinstance(type, type)
>True
>>>> isinstance(3, type)
>False
>>>> isinstance(int, 3)
>Traceback (most recent call last):
>  File "", line 1, in 
>TypeError: isinstance() arg 2 must be a type or tuple of types
>>>> isinstance(3, object)
>True
>>>> isinstance("3", object)
>True
>>>> isinstance(int, object)
>True
>>>> isinstance(type, object)
>True
>>>> isinstance(object, object)
>True
> 
> 
> Marko


neat
Maybe add also

>>> isinstance(type,object)
True
>>> isinstance(object,object)
True
>>> issubclass(object,type)
False
>>> issubclass(type,object)
True
>>> isinstance(object,type)
True
>>> issubclass(int,object)
True
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mark Lawrence]

On 28/01/2015 00:52, Mario Figueiredo wrote:

In article ,
breamore...@yahoo.co.uk says...


Mario and Andre, when you have to write code to meet the deadline to get
the stage payment, does either of your bosses really care whether or not
you are dealing with an object, an instance, or a piece of dead meat
dropped by the neighbour's cat?


That is valuable input. You don't care how a type or an instance of a
type differ. Should be intersting to ask you to make a Cat object. I
wonder if you are not going to ask if they mean a class or an instance
of that class.

Anyways, more to the point, this is simply a debate on language and how
to express Python concepts. If that bothers you, I'll take note.



The thing that bothers me is that many people, some of them with maybe 
20 years of Python experience, have repeatedly stated Python concepts 
with respect to the terms class, instance and object.  Instead of 
accepting their knowledge of the language and gracefully stepping back, 
you've carried on until the twist of knots would make any boy scout proud.


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

Mark Lawrence

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

Re: An object is an instance (or not)?

[random832]

On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
> On Tue, Jan 27, 2015 at 9:37 PM,   wrote:
> > Sub itself is not a Sub object, it is a type object. "instance" is
> > implicit in the phrase "foo object".
> 
> Yes. Unfortunately, it's still not really completely clear. "Sub
> instance" would avoid this confusion for everyone.

It really is completely clear. Nobody is confused but you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 11:31:46 AM UTC+5:30, random wrote:
> On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
> > On Tue, Jan 27, 2015 at 9:37 PM,  random832 wrote:
> > > Sub itself is not a Sub object, it is a type object. "instance" is
> > > implicit in the phrase "foo object".
> > 
> > Yes. Unfortunately, it's still not really completely clear. "Sub
> > instance" would avoid this confusion for everyone.
> 
> It really is completely clear. Nobody is confused but you.

I think I can count 4 people
OP trying to show the confusion (maybe confusedly)
Ben agreeing that some terminology could be straightened out
Devin agreeing with Ben
Me(Rusi): Prefer a not so cavalier adjective-noun equivalencing
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

random...@fastmail.us writes:

> On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
> > On Tue, Jan 27, 2015 at 9:37 PM,   wrote:
> > > Sub itself is not a Sub object, it is a type object. "instance" is
> > > implicit in the phrase "foo object".
> > 
> > Yes. Unfortunately, it's still not really completely clear. "Sub
> > instance" would avoid this confusion for everyone.
>
> It really is completely clear. Nobody is confused but you.

You have no justification to claim that, and it's hostile and dismissive
to claim it so assertively.

I'll freely admit to finding “'Foo' object” ambiguous. It can reasonably
be interpreted to mean either “a 'Foo' object” (⇒ “an object of class
'Foo'”), or “the 'Foo' object” (⇒ “the object referred to by the name
'Foo'”). The error message which inspired this thread needs improvement,
as I've said already.

Let's not dismiss anyone's experience without good reason.

-- 
 \ “When people believe that they have absolute knowledge, with no |
  `\ test in reality, this [the Auschwitz crematorium] is how they |
_o__) behave.” —Jacob Bronowski, _The Ascent of Man_, 1973 |
Ben Finney

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

Re: An object is an instance (or not)?

[Ben Finney]

Rustom Mody  writes:

> Me(Rusi): Prefer a not so cavalier adjective-noun equivalencing

I can sympathise with that preference. It really is a lost cause,
though; the English language just works that way.

We use nouns as verbs, nouns as modifiers, adjectives as nouns; and
rather than wish it were not so, we must to take care to express
ourselves to avoid unintended ambiguity — especially in writing. And
*especially* in writing terse formal error messages.

The English language is imperfect, but it's what we have. Live with it.

-- 
 \  “The manager has personally passed all the water served here.” |
  `\  —hotel, Acapulco |
_o__)  |
Ben Finney

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

Re: unicode question

[Terry Reedy]

On 1/27/2015 12:17 AM, Rehab Habeeb wrote:

Hi there python staff
does python support arabic language for texts ? and what to do if it
support it?
i wrote hello in Arabic using codeskulptor and the powershell just for
testing and the same error appeared( a sytanx error in unicode)!!


I do not know how complete the support is, but this is copied from 
3.4.2, which uses tcl/tk 8.6.

>>> t = "الحركات"
>>> for c in t: print(c)  # Prints rightmost char above first
ا
ل
ح
ر
ك
ا
ت

The following StackOverflow question and response indicate that there 
may b more issue, but it was asked before tcl/tk 8.6 was available, so 
the answer may be partially obsolete.



--
Terry Jan Reedy


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

Re: An object is an instance (or not)?

[Gregory Ewing]

Mario Figueiredo wrote:
That error message has me start that thread arguing that the error is 
misleading because the Sub object does have the __bases__ attribute. 
It's the Sub instance object that does not have it.


Some of the answers that were given argued that in Python object = 
instance.


No, they pointed out that *in that particular sentence* the
word "object" was being used in a way that's more or less
synonymous with "instance".

But that doesn't mean the two words are perfectly
interchangeable in all English sentences. Sometimes one
is better than the other.

I prefer to use the word "instance" when I'm talking about
an instance *of* something, e.g. "an instance of Foo" or
"a Foo instance". If I'm not mentioning a class, I just
use the word "object".

So I would argue that "Sub instance has no attribute..."
is a marginally clearer way to word that message.

Which means, I think, that I'm more or less agreeing with
you, but *not* because of objects not always being instances
in Python. On the contrary, it's precisely because all
objects *are* instances that using the word "instance"
on its own in place of "object" is pointless -- it
doesn't convey any extra information.

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

Re: An object is an instance (or not)?

[Ben Finney]

Devin Jeanpierre  writes:

> […] as Ben Finney pointed out. (BTW I agree with literally every
> single thing he said in this thread, it's really amazing.)

Hmm, writing that doesn't annoy somebody is not worth writing [0].

It shouldn't annoy *everyone* though, so I'm glad to know you can agree
with me this time :-)


[0] often attributed to Kingley Amis, as “If you can't annoy somebody,
there's little point in writing.” though I can't find the source for
that aphorism.

-- 
 \ “Facts are stubborn things; and whatever may be our wishes, our |
  `\   inclinations, or the dictates of our passion, they cannot alter |
_o__)the state of facts and evidence.” —John Adams, 1770-12-04 |
Ben Finney

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