Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Mon, 14 May 2018 21:24:01 -0400, Dennis Lee Bieber wrote:


>   The problem with adding the feature is that it will start to be
> used by
> newbies who lack the discipline to use it reliably: ensuring that
> comparisons are coded with constants (which for Python really means
> literals) on the left-hand side, so that a type of "=" for "==" will be
> flagged and not transparently pass.


Using = alone is absolutely not on the table.

The current two leading contenders, both controversial, are:

name := expression

name given name = expression


The second is being sponsored, backed, supported and subsidised by the 
Department of Repeated Redundancy and Repetitiveness.

(And before you ask, unfortunately "expression as name" has been ruled 
out because it is ambiguous with other uses of "as".


-- 
Steve

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

Extract data from multiple text files

[mahesh d]

import glob,os

import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'

files = glob.glob(path)

'''for name in files:

print(str(name))

if name.endswith(".txt"):

   print(name)'''

for file in os.listdir(path):

print(file)

if file.endswith(".txt"):

print(os.path.join(path, file))

print(file)

try:

with open(file) as f:

msg = f.read()

print(msg)

except IOError as exc:

if exc.errno != errno.EISDIR:

raise


In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them


 How can resolve those error
-- 
https://mail.python.org/mailman/listinfo/python-list

Read data from .msg all files

[mahesh d]

import glob

import win32com.client



files = glob.glob('C:/Users/A-7993/Desktop/task11/sample emails/*.msg')

for file in files:

print(file)

with open(file) as f:

msg=f.read()

print(msg)

outlook =
win32com.client.Dispatch("Outlook.Application").GetNamespace("MAPI")

msg = outlook.OpenSharedItem(file)

print("FROM:", str(msg.SenderName))

print(msg.SenderEmailAddress)

print(msg.SentOn)

print(msg.To)

print(msg.CC)

print(msg.BCC)

print(msg.Subject)

print(msg.Body)


How can read all .msg files in a folder. I used outlook.openshared item it
only works one file . How can read the data from .msg files
-- 
https://mail.python.org/mailman/listinfo/python-list

Uploading on PyPI fail

[Vincent Vande Vyvre]

Hi,

Trying to upgrade a package on PyPI, I get this error:

$ python3 setup.py register sdist upload
...
Submitting dist/py3exiv2-0.3.0.tar.gz to https://pypi.python.org/pypi
Upload failed (308): Redirect to Primary Domain
error: Upload failed (308): Redirect to Primary Domain

I know the site has changed but what is changed for me ?

This is the content of my .pypirc:
-
[distutils]
index-servers=
    pypi
    pypitest

[pypitest]
repository = https://test.pypi.org/legacy/
username = VinsS
password = ***

[pypi]
repository = https://upload.pypi.org/legacy/
username = VinsS
password = **
-

Note: I've tested on test.pypi.org without problems.

Thanks for all advices,

Vincent

(send at Tue, 15 May 2018 12:04:10 +0200)

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

Re: Uploading on PyPI fail (solved)

[Vincent Vande Vyvre]

Le 15/05/18 à 12:05, Vincent Vande Vyvre a écrit :

Hi,

Trying to upgrade a package on PyPI, I get this error:

$ python3 setup.py register sdist upload
...
Submitting dist/py3exiv2-0.3.0.tar.gz to https://pypi.python.org/pypi
Upload failed (308): Redirect to Primary Domain
error: Upload failed (308): Redirect to Primary Domain

I know the site has changed but what is changed for me ?

This is the content of my .pypirc:
-
[distutils]
index-servers=
    pypi
    pypitest

[pypitest]
repository = https://test.pypi.org/legacy/
username = VinsS
password = ***

[pypi]
repository = https://upload.pypi.org/legacy/
username = VinsS
password = **
-

Note: I've tested on test.pypi.org without problems.

Thanks for all advices,

Vincent

(send at Tue, 15 May 2018 12:04:10 +0200)


Solved with $ twine upload  dist/*


...

Vincent

(send at Tue, 15 May 2018 14:34:10 +0200)


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

Re: Extract data from multiple text files

[Rhodri James]

On 15/05/18 13:12, mahesh d wrote:

import glob,os
import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'
files = glob.glob(path)

for file in os.listdir(path):
 print(file)
 if file.endswith(".txt"):
 print(os.path.join(path, file))
 print(file)
 try:
 with open(file) as f:
 msg = f.read()
 print(msg)
 except IOError as exc:
 if exc.errno != errno.EISDIR:
 raise


In the above program . Getting lot of errors .


What errors?  Please cut and paste the traceback (don't retype it, and 
definitely don't send us screenshots; attachments aren't allowed on the 
mailing list).



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

Re: Pandas cat.categories.isin list, is this a bug?

[Matt Ruffalo]

On 2018-05-15 06:23, Zoran Ljubišić wrote:
> Matt,
>
> thanks for the info about pydata mailing group. I didn't know it exists.
> Because comp.lang.python is not appropriate group for this question, I
> will continue our conversation on gmail.
>
> I have put len(df.CRM_assetID.cat
> .categories.isin(['V1254748', 'V805722',
> 'V1105400']))  = 55418 in next message, after I noticed that this
> information is missing.
>
> If I want to select all rows that have categories from the list, how
> to do that?
>
> Regards,
>
> Zoran
>

Hi Zoran-

(Including python-list again, for lack of a reason not to. This
conversation is still relevant and appropriate for the general Python
mailing list -- I just meant that the pydata list likely has many more
Pandas users/experts, so you're more likely to get a better answer,
faster, from a more specialized group.)

Selecting all rows that have categories is a bit simpler than what you
are doing -- your issue is that you are working with the *set of
distinct categories*, and not the actual vector of categories
corresponding to your data.

You can select items you're interested in with something like the following:

"""
In [1]: import pandas as pd

In [2]: s = pd.Series(['apple', 'banana', 'apple', 'pear', 'banana',
'cherry', 'pear', 'cherry']).astype('category')

In [3]: s
Out[3]:
0 apple
1    banana
2 apple
3  pear
4    banana
5    cherry
6  pear
7    cherry
dtype: category
Categories (4, object): [apple, banana, cherry, pear]

In [4]: s.isin({'apple', 'pear'})
Out[4]:
0 True
1    False
2 True
3 True
4    False
5    False
6 True
7    False
dtype: bool

In [5]: s.loc[s.isin({'apple', 'pear'})]
Out[5]:
0    apple
2    apple
3 pear
6 pear
dtype: category
Categories (4, object): [apple, banana, cherry, pear]
"""

(Note that I'm also passing a set to `isin` instead of a list -- this
doesn't matter when looking for two or three values, but if you're
passing 1000 values to `isin`, or 10_000, or 1_000_000, then linear-time
membership testing can start to become an issue.)

You are accessing the vector of the *unique categories* in that column, like

"""
In [6]: s.cat.categories
Out[6]: Index(['apple', 'banana', 'cherry', 'pear'], dtype='object')

In [7]: s.cat.categories.isin({'apple', 'pear'})
Out[7]: array([ True, False, False,  True])
"""

The vector `s.cat.categories` has one element for each distinct category
in your column, and your column apparently contains 55418 different
categories.

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

Re: Read data from .msg all files

[Grant Edwards]

On 2018-05-15, mahesh d  wrote:

> import glob

_Please_ stop creating new threads for this question.  I think this is
the fifth thread you've started for what appears to be a single
question.

-- 
Grant Edwards   grant.b.edwardsYow! Like I always say
  at   -- nothing can beat
  gmail.comthe BRATWURST here in
   DUSSELDORF!!

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

Re: object types, mutable or not?

[Mike McClain]

On Sun, May 13, 2018 at 07:10:11PM -0400, Richard Damon wrote:
> On 5/13/18 4:02 PM, Mike McClain wrote:
> > I'm new to Python and OOP.
> > Python  en 2.7.14 Documentation  The Python Language Reference
> > 3. Data model
> > 3.1. Objects, values and types
> > An object's type is also unchangeable. [1]
> > [1] It is possible in some cases to change an object's type,
> > under certain controlled conditions.
> >
> > It appears to me as if an object's type is totally mutable and
> > solely dependant on assignment.
> >
>  obj = 'a1b2'
>  obj
> > 'a1b2'

> > At what level does my understanding break down?


> The first this is obj is NOT 'the object', but is instead a reference
> that 'points' to an object.

Many thanks to those teachers who responded.

I think I got it.
The variable is not the object just as the name is not the thing.

I had gotten the impression that everything in OOP is an object but
you're all saying that variables are not objects.

Does a variable have a type?
If so what is the type of a variable and how is that demonstrated
if 'type()' reports what the variable points to?

Thanks,
Mike
--
Men occasionally stumble over the truth, but most of them pick
themselves up and hurry off as if nothing ever happened.
- Churchill
-- 
https://mail.python.org/mailman/listinfo/python-list

What's the rationale for b"..." in this example?

[Skip Montanaro]

Consider this:

>>> bytes("abc", encoding="utf-8")
b'abc'

Looks reasonable. Then consider this:

>>> str(bytes("abc", encoding="utf-8"))
"b'abc'"

Why is the b'...' bit still there? I suppose it's because I didn't tell it
explicitly how to decode the bytes object, as when I do, I get the expected
result:

>>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
'abc'

Coming from a still largely Python 2 perspective, did all attempts to apply
default encodings disappear in Python 3?

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

Re: object types, mutable or not?

[Rhodri James]

On 15/05/18 15:29, Mike McClain wrote:

On Sun, May 13, 2018 at 07:10:11PM -0400, Richard Damon wrote:

On 5/13/18 4:02 PM, Mike McClain wrote:

I'm new to Python and OOP.
Python  en 2.7.14 Documentation  The Python Language Reference
3. Data model
3.1. Objects, values and types
An object's type is also unchangeable. [1]
[1] It is possible in some cases to change an object's type,
 under certain controlled conditions.

It appears to me as if an object's type is totally mutable and
solely dependant on assignment.


obj = 'a1b2'
obj

'a1b2'



At what level does my understanding break down?




The first this is obj is NOT 'the object', but is instead a reference
that 'points' to an object.


Many thanks to those teachers who responded.

I think I got it.
The variable is not the object just as the name is not the thing.

I had gotten the impression that everything in OOP is an object but
you're all saying that variables are not objects.

Does a variable have a type?
If so what is the type of a variable and how is that demonstrated
if 'type()' reports what the variable points to?


Variables don't have types, or indeed anything much.  They are just 
names, that's all.  Every time you use the name, you get the object the 
name references (or "is bound to" as some people prefer to phrase it).


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

Re: What's the rationale for b"..." in this example?

[Ethan Furman]

On 05/15/2018 08:14 AM, Skip Montanaro wrote:

Consider this:


bytes("abc", encoding="utf-8")

b'abc'

Looks reasonable. Then consider this:


str(bytes("abc", encoding="utf-8"))

"b'abc'"

Why is the b'...' bit still there?


Because you are printing a bytes object, not a str.


I suppose it's because I didn't tell it
explicitly how to decode the bytes object, as when I do, I get the expected
result:


str(bytes("abc", encoding="utf-8"), encoding="utf-8")

'abc'

Coming from a still largely Python 2 perspective, did all attempts to apply
default encodings disappear in Python 3?


Pretty much, yup.  There is no more guessing what encoding to use -- either specify it, or be made aware that you 
printed a bytes object.


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

Simplest way to clobber/replace one populated directory with another?

[Travis Griggs]

I have a directory structure that might look something like:

Data
Current
A
B 
C 
Previous
A 
X

In as simple/quick a step as possible, I want to rename Current as Previous 
including the contents and wiping out the original such that it is now:

Data
Previous
A
B
C

I've tried something like:

from pathlib import Path
src = Path('Data/Current’)
dest = Path('Data/Previous’)
src.replace(dest)

The docs led me to hope this would work:

"If target points to an existing file or directory, it will be 
unconditionally replaced.”

But it *does* appear to be conditional. I get a "Directory not empty" 
exception. I guess I could recursively delete the ‘Previous' directory first. 
Is that basically the only solution? Or is there a better way to achieve this?

(I prefer `pathlib`, but if `os` or `shutil` is the better hammer here, I'm not 
opposed to them)

(I am running on Linux)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Python]

On Tue, May 15, 2018 at 12:52:42AM +, Steven D'Aprano wrote:
> But you miss the point that even if = versus == errors are picked up by 
> code reviews or tests, they are still software bugs. Your *process* 
> (testing and reviews) picked up the bug before they went into production, 
> but *the bug still was made*.

I do not miss this point.  My premise from the beginning was that
humans make mistakes, this bug will occur, and most importantly it's
no worse than any other bug.  Wrong code is wrong code.  YOU'RE GOING
TO SCREW UP, and you need *SOMETHING* in place to catch that.  It may
as well also catch this, and it's NOT that hard to do... If you had no
other tools, you could write a regex to scan your code for it and
review the matches.  If you never discovered that this was a
well-known pitfall that's one thing, but I've known about it since
approximately 1986--it's been around a long time as you yourself say,
so there's no excuse for someone now, 30+ years later, not knowing
about it and watching out for it... unless they simply don't care
about writing working code and so put no effort into learning about
such things.

The noob argument only reinforces my point--they're going to screw up
all manner of things, until they learn not to...  The noob argument is
only a worse example of the same reason why we have software
development process (and mentors).  If you're in the unfortunate
position you described, where you don't have peer review, then you
need to employ good proccess EVEN MORE, because you have only yourself
to rely on.  If you don't employ it, it's pretty much a guanrantee
that your software quality will be sub par, unless you are a true
superstar.  [They exist, I've come to know a small handful.
Unfortunately I am not one of them.]

Seperately, I asserted that you can, if you really want to, learn to
not make this mistake, BUT IT'S NOT RELEVANT TO MY POINT.  In life we
learn to stop making all manner of mistakes, and reduce the frequency
of others.  In nearly half a century of life, I've NEVER made the
mistake of putting my hand on a hot stove burner, because I've learned
that it's dangerous, and take extra care around hot stove burners.  To
me this bug is exactly the same.  Likewise I'm POSITIVE there are
types of mistakes that YOU never make, though this bug may not be one
of them.  I'm certain it can be one that you learn to not make, if you
exert the required effort, whatever it may be *for you*.  But I must
admit that neither of us can conclusively prove the other wrong, and
you will likely believe whatever you've convinced yourself of already,
just as I do, and that's fine.  

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

Re: Extract data from multiple text files

[MRAB]

On 2018-05-15 13:12, mahesh d wrote:

import glob,os

import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'

files = glob.glob(path)

'''for name in files:

 print(str(name))

 if name.endswith(".txt"):

print(name)'''

for file in os.listdir(path):

 print(file)

 if file.endswith(".txt"):

 print(os.path.join(path, file))

 print(file)

 try:

 with open(file) as f:

 msg = f.read()

 print(msg)

 except IOError as exc:

 if exc.errno != errno.EISDIR:

 raise


In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them


  How can resolve those error

You don't say what the errors are, but I'm guessing that it's 
complaining that it can't find the file with trying to open it.


'open' needs the _full path_ to the file, but 'os.listdir' returns only 
the _name_ of the files and directories, not the full path.

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

Re: object types, mutable or not?

[Ben Finney]

Mike McClain  writes:

> Many thanks to those teachers who responded.

Thank you for asking the question in a way that allows the discussion
:-)

> I think I got it.
> The variable is not the object just as the name is not the thing.

Yes. The term “variable” is so overloaded, for people new to Python,
that I prefer to avoid it altogether. I discuss Python's assignment
behaviour in terms of binding and references.

> I had gotten the impression that everything in OOP is an object

That is definitely not true. There are many languages that support OOP
where *not* everything is an object.

See 
https://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages.

> but you're all saying that variables are not objects.

Yes. In the “everything is an object” adage, it's important to realise
what ontology is being used — what “things” exist.

It would be more accurate to say “every value is an object”, but that
gets into how “value” has technical meanings and is IMO less helpful
than “everything is an object”.

A different formulation to make it more accurate would be “everything
that can be addressed by an expression is an object”. Not as catchy, and
I don't expect to see it used as often :-)

The point being, there are many things *we* can talk about which don't
“exist” as things in the context of that adage. Numbers, file handles,
data structures all are “things” and therefore are objects in Python.

Variables, sequence indexes, memory locations, names, statements are
concepts with meaning when *talking about* Python, but are not “things”
that have a value in a Python expression. Because they are not “things”
in Python, those are not objects in Python.

The adage is intended (IIUC) to contrast with languages other than
Python that *do* support OOP, but where *not* everything is an object.
Examples include Java, PHP, Pascal.

> Does a variable have a type?

No, because in Python, “variable” refers to the *binding* between a
reference and an object. In that binding, only the object has a type,
and its type is totally unaffected by whatever references are bound to
that object.

> If so what is the type of a variable and how is that demonstrated
> if 'type()' reports what the variable points to?

This is an illustration of why I don't find “variable” a helpful term
for discussing Python behaviour.

Instead, an expression like ‘type(foo)’ is better understood as getting
the type of object that the name ‘foo’ references.

It doesn't make sense to ask “what is the type of foo” if you're
thinking of ‘foo’ the name. The type is not a property of the name and
not a property of the name–object binding (the “variable”). The type is
a property of the object.

-- 
 \ “It is the fundamental duty of the citizen to resist and to |
  `\  restrain the violence of the state.” —Noam Chomsky, 1971 |
_o__)  |
Ben Finney

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

Re: What's the rationale for b"..." in this example?

[Ben Finney]

Skip Montanaro  writes:

> Consider this:
>
> >>> bytes("abc", encoding="utf-8")
> b'abc'
>
> Looks reasonable. Then consider this:
>
> >>> str(bytes("abc", encoding="utf-8"))
> "b'abc'"
>
> Why is the b'...' bit still there?

Because the bytes object is asked for a text representation of itself,
and the text value ‘b'abc'’ is what it returned.

> I suppose it's because I didn't tell it explicitly how to decode the
> bytes object, as when I do, I get the expected result:
>
> >>> str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'

Yes.

> Coming from a still largely Python 2 perspective, did all attempts to
> apply default encodings disappear in Python 3?

To the extent I understand that question, the answer is no.

Rather, the ‘bytes’ and ‘str’ types are now entirely incompatible, and
implicit conversions are never done between them. Any conversions
between them must be explicit.

-- 
 \“There are always those who think they know what is your |
  `\  responsibility better than you do.” —Ralph Waldo Emerson |
_o__)  |
Ben Finney

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

Re: What's the rationale for b"..." in this example?

[Serhiy Storchaka]

15.05.18 18:14, Skip Montanaro пише:

Consider this:


bytes("abc", encoding="utf-8")

b'abc'

Looks reasonable. Then consider this:


str(bytes("abc", encoding="utf-8"))

"b'abc'"

Why is the b'...' bit still there? I suppose it's because I didn't tell it
explicitly how to decode the bytes object, as when I do, I get the expected
result:


str(bytes("abc", encoding="utf-8"), encoding="utf-8")

'abc'


str() without 'encoding' and 'errors' calls __str__ which falls back to 
__repr__ by default.


bytes.__str__ falls back to bytes.__repr__, this makes errors of mixing 
bytes and strings more obvious. If run Python with the -b option, it 
will emit a BytesWarning first. If run it with -bb, it will become an error.


You can receive many interesting warning when run Python 2 with options 
-b and -3. Getting rid of these warnings will help with porting to 
Python 3 and may fix real bugs.


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

Re: What's the rationale for b"..." in this example?

[Chris Angelico]

On Wed, May 16, 2018 at 1:14 AM, Skip Montanaro
 wrote:
> Consider this:
>
 bytes("abc", encoding="utf-8")
> b'abc'
>
> Looks reasonable. Then consider this:
>
 str(bytes("abc", encoding="utf-8"))
> "b'abc'"
>
> Why is the b'...' bit still there? I suppose it's because I didn't tell it
> explicitly how to decode the bytes object, as when I do, I get the expected
> result:
>
 str(bytes("abc", encoding="utf-8"), encoding="utf-8")
> 'abc'
>
> Coming from a still largely Python 2 perspective, did all attempts to apply
> default encodings disappear in Python 3?

It's there for the same reason as the square brackets here:

>>> str(list('abc'))
"['a', 'b', 'c']"

Calling str() on arbitrary objects returns a printable string; and in
Py3, there's simply nothing special about bytes. Personally, I never
use the str(..., encoding="...") notation; I prefer to use the
.decode() method of the bytes object.

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

syntax oddities

[Tobiah]

Why is it len(object) instead of object.len?

Why is it getattr(object, item) rather then object.getattr(item)?

etc...


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

Re: Extract data

[Albert-Jan Roskam]

On May 15, 2018 08:54, Steven D'Aprano  
wrote:

On Tue, 15 May 2018 11:53:47 +0530, mahesh d wrote:

> Hii.
>
>  I have folder.in that folder some files .txt and some files .msg files.
>  .
> My requirement is reading those file contents . Extract data in that
> files .

Reading .msg can be done with win32com or 
https://github.com/mattgwwalker/msg-extractor

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

Re: syntax oddities

[Serhiy Storchaka]

15.05.18 22:10, Tobiah пише:

Why is it len(object) instead of object.len?


Because the first form looked better to Guido van Rossum.


Why is it getattr(object, item) rather then object.getattr(item)?


How do you get the 'getattr' attribute then?

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

Re: seeking deeper (language theory) reason behind Python design choice

[Peter J. Holzer]

On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
> Now remember that in 1991 when Guido made the decision to ban = as an 
> expression, those concepts didn't even exist. There were no Python 
> linters, and no reason to imagine that there ever would be. Guido didn't 
> know that Python would become one of the top 10 most used languages. For 
> all he knew, version 1.0 could be the final release.
> 
> By 1991 there had already been *decades* of experience with C

About one and a half decades.

> proving that the "=" assignment syntax is dangerously confusable with
> == and a total bug magnet when allowed as expressions as well, so it
> was perfectly reasonable to ban it from the language.

Experience? Yes. Data? I doubt it.

I will readily admit that my knowledge of research into the usability
of programming languages is more than spotty, but I have read a few
papers about the topic over the last decade. I don't recall any which
quantified "bug magnets" under realistic conditions (two hour toy
problems for first-year students don't count). I thought there was one
by Google, but that was about compile-time errors.

Language design ist still mostly an art driven by gut feeling, not
engineering driven by data. I doubt that this was better in 1991.

I have been programming in C since the mid-80's and in Perl since the
mid-90's (both languages allow assignment expressions). I accumulated my
fair share of bugs in that time, but AFAIR I made this particular error
very rarely (I cannot confidently claim that I never made it). Clearly
it is not “a total bug magnet” in my experience. There are much bigger
problems in C and Perl (and Python, too). But of course my experience is
just that of a single programmer (or a handful if I include people
whose code I've reviewed or debugged) and in any case just anecdotal.
(Could I quantify even my own experience? I guess I could write a script
which searches through all my repositories for changesets where “=” was
replaced by “==”. Not sure what that would prove.)

OTOH, despite having used C and Perl long before Python, I don't miss
assignment expressions. Every language has its idioms, and just because
you write stuff like “if ((fd = open(...)) == -1)” a lot in C doesn't
mean you have to be able to write that in Python.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


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

Re: syntax oddities

[Ian Kelly]

On Tue, May 15, 2018 at 1:10 PM, Tobiah  wrote:
> Why is it len(object) instead of object.len?
>
> Why is it getattr(object, item) rather then object.getattr(item)?

http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the rationale for b"..." in this example?

[Skip Montanaro]

> Personally, I never use the str(..., encoding="...") notation; I prefer
to use the
> .decode() method of the bytes object.

Thanks. And thanks for the other responses. I obviously didn't have my
thinking cap on this morning. (It was too late in the morning to plead lack
of coffee.)

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

Re: Extract data from multiple text files

[Albert-Jan Roskam]

On May 15, 2018 14:12, mahesh d  wrote:

import glob,os

import errno

path = 'C:/Users/A-7993\Desktop/task11/sample emails/'

files = glob.glob(path)

'''for name in files:

print(str(name))

if name.endswith(".txt"):

   print(name)'''

for file in os.listdir(path):

print(file)

if file.endswith(".txt"):

print(os.path.join(path, file))

print(file)

try:

with open(file) as f:

msg = f.read()

print(msg)

except IOError as exc:

if exc.errno != errno.EISDIR:

raise


In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them


How can resolve those error
--
https://mail.python.org/mailman/listinfo/python-list

Try:
path = 'C:/Users/A-7993/Desktop/task11/sample emails/*.msg'
msg_files = glob.glob(path)
print(msg_files)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the rationale for b"..." in this example?

[Chris Angelico]

On Wed, May 16, 2018 at 9:02 AM, Skip Montanaro
 wrote:
>> Personally, I never use the str(..., encoding="...") notation; I prefer
> to use the
>> .decode() method of the bytes object.
>
> Thanks. And thanks for the other responses. I obviously didn't have my
> thinking cap on this morning. (It was too late in the morning to plead lack
> of coffee.)

You plead lack of coffee until you plead caffeine overdose. That's the
way of things. :)

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

Re: object types, mutable or not?

[Steven D'Aprano]

On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:

> I had gotten the impression that everything in OOP is an object but
> you're all saying that variables are not objects.

Perhaps it is better to say every VALUE in Python is an object.

Keywords aren't values. Operators aren't values. Comments aren't values. 
Expressions like "5 + 3*x" themselves aren't values, but they evaluate to 
a value. Neither are variables/names.

Variables *hold* values, or if you prefer, names refer to values. But 
since they aren't themselves values, names/variables aren't objects.

> Does a variable have a type?

In Python, no, variables don't have types. Python uses *dynamic typing* 
which we can simplify a little and describe as:

- variables are just labels that can refer to any value;

- values are typed;

- the interpreter checks that types are compatible at runtime,
  when the code is executed

(e.g. "1 + 2" is permitted, but "1 + []" is not).


The most common alternative is *static typing*, where:

- variables are typed;

- variables are labels that can only refer to a value that matches
  that type;

- the compiler checks that types are compatible at compile-time,
  before the code is executed.



-- 
Steve

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

Re: syntax oddities

[Steven D'Aprano]

On Tue, 15 May 2018 12:10:07 -0700, Tobiah wrote:

> Why is it len(object) instead of object.len?

Because we're not serfs in the Kingdom of Nouns:

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


-- 
Steve

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

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:

> On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
[...]
>> By 1991 there had already been *decades* of experience with C
> 
> About one and a half decades.

That would still be plural decades.

C's first release was 1972, so more like 19 years than 15. That's just 
under two decades.


>> proving that the "=" assignment syntax is dangerously confusable with
>> == and a total bug magnet when allowed as expressions as well, so it
>> was perfectly reasonable to ban it from the language.
> 
> Experience? Yes. Data? I doubt it.

I'm using "proving" informally above, not in the sense of actual legal or 
scientific standards of proof.

If you are going to object to that, remember that neither is there 
scientific data proving that assignment as an expression is useful, so we 
can always just reject the construct as "useless until proven otherwise" 
:-)


> I will readily admit that my knowledge of research into the usability of
> programming languages is more than spotty, but I have read a few papers
> about the topic over the last decade. I don't recall any which
> quantified "bug magnets" under realistic conditions (two hour toy
> problems for first-year students don't count). I thought there was one
> by Google, but that was about compile-time errors.
> 
> Language design ist still mostly an art driven by gut feeling, not
> engineering driven by data. I doubt that this was better in 1991.
> 
> I have been programming in C since the mid-80's [...]
> I guess I could write a script which
> searches through all my repositories for changesets where “=” was
> replaced by “==”. Not sure what that would prove.)

You were using version control repositories in the 1980s, and still have 
access to them? I'm impressed.


> OTOH, despite having used C and Perl long before Python, I don't miss
> assignment expressions. Every language has its idioms, and just because
> you write stuff like “if ((fd = open(...)) == -1)” a lot in C doesn't
> mean you have to be able to write that in Python.

I'm not a C coder, but I think that specific example would be immune to 
the bug we are discussing, since (I think) you can't chain assignments in 
C. Am I right?

fd = open(...)) = -1

would be a syntax error. But:

fd = -1

would not be.



-- 
Steve

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

Re: seeking deeper (language theory) reason behind Python design choice

[bartc]

On 15/05/2018 21:21, Peter J. Holzer wrote:


I have been programming in C since the mid-80's and in Perl since the
mid-90's (both languages allow assignment expressions). I accumulated my
fair share of bugs in that time, but AFAIR I made this particular error
very rarely (I cannot confidently claim that I never made it). Clearly
it is not “a total bug magnet” in my experience. There are much bigger
problems in C and Perl (and Python, too). But of course my experience is


All those languages use = for assignment and == for equality.

If like me you normally use a language where = means equality (and := is 
used for assignment), then you're going to get it wrong more frequently 
when using C or Python (I don't use Perl).


You might get it wrong anyway because = is used for equality in the real 
world too.


And it's an error that is awkward to detect (in C anyway, as it would be 
an error in Python) because usually both = and == are plausible in an 
expression.


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

Re: seeking deeper (language theory) reason behind Python design choice

[bartc]

On 16/05/2018 01:04, Steven D'Aprano wrote:


I'm not a C coder, but I think that specific example would be immune to
the bug we are discussing, since (I think) you can't chain assignments in
C. Am I right?


Assignments can be chained in C (with right-to-left precedence) as can 
augmented assignments (+= and so on).


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

stock quotes off the web, py style

[Mike McClain]

Initially I got my quotes from a broker daily to plug into a
spreadsheet, Then I found Yahoo and wrote a perl script to grab them.
When Yahoo quit supplying quotes I found AlphaVantage.co and rewrote
the perl script.
AlphaVantage.co has been down since last week and I found
iextrading.com has a freely available interface. Since it needs
a rewrite and I'm trying to get a handle on python this seems
like a good opportunity to explore.
If someone would please suggest modules to explore. Are there any
upper level modules that would allow me to do something like:

from module import get
def getAquote(symbol):
url = 'https://api.iextrading.com/1.0/stock/()/quote'.format(symbol)
reply = module.get(url)
return my_parse(reply)

Thanks,
Mike
--
Men occasionally stumble over the truth, but most of them pick
themselves up and hurry off as if nothing ever happened.
- Churchill
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: object types, mutable or not?

[Ben Finney]

Steven D'Aprano  writes:

> On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:
>
> > I had gotten the impression that everything in OOP is an object but
> > you're all saying that variables are not objects.
>
> Perhaps it is better to say every VALUE in Python is an object.

IMO that is better than using the term “variable”, which carries baggage
from other languages when people try learning Python.

But not good enough. It was you, Steven (I think?) who taught me that
using the term “value” interchangeably with “object” is problematic.

That's because, in Python an object can remain the same object, while
its value changes.

>>> foo = [1, 2, 3]# A new list now exists.
>>> foo.append(4)  # It's the same object, but now its value is 
different.

Therefore, an object is not its value (otherwise, when the value
changes, we necessarily have a different object. That's false, and so
the equivalence is also false.)

An object is not a value; an object *has* a value. The object retains
its identity even when its value changes.

> Variables *hold* values, or if you prefer, names refer to values. But
> since they aren't themselves values, names/variables aren't objects.

I really want that sentence to be useful for this pedagogical purpose.
My earlier message in this thread went to some length to do something
similar.

But because we only invite later confusion when the “a value is an
object” false equivalence needs un-learning, I can't let it pass.

-- 
 \“The idea that He would take his attention away from the |
  `\   universe in order to give me a bicycle with three speeds is |
_o__)  just so unlikely that I can't go along with it.” —Quentin Crisp |
Ben Finney

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

Re: Extract data from multiple text files

[Cameron Simpson]

On 15May2018 18:18, MRAB  wrote:

On 2018-05-15 13:12, mahesh d wrote:

import glob,os

[...]

files = glob.glob(path)


You've got a list of filenames here - they would work, _if_ you had passed in a 
glob pattern, instead of just the directory path. Try this again, joining 
"*.msg" or "*.txt" to the path.



for file in os.listdir(path):


As MRAB has mentioned, this just gets the file basenames. You need to join them 
to the directory path to get the proper pathname.


[...snop...]

In the above program . Getting lot of errors . My intention is read the
list of the text files in a folder . Print them
 How can resolve those error


Please _always_ include a text transcript of the errors, inline in the message 
(not as an attached file).


You don't say what the errors are, but I'm guessing that it's 
complaining that it can't find the file with trying to open it.


'open' needs the _full path_ to the file, but 'os.listdir' returns 
only the _name_ of the files and directories, not the full path.


In particular, since it may not be obvious how to do this correctly:
import the os.path module and look at the os.path.join function.

And finally, _please_ post follow on questions to this list as _replies_ to the 
appropriate list message. By just posting new messages from scratch your new 
message is disconnected from all the earlier ones. Anyone trying to follow your 
discussion will lose all the other context.


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list

Re: object types, mutable or not?

[Steven D'Aprano]

On Wed, 16 May 2018 11:30:26 +1000, Ben Finney wrote:

> Steven D'Aprano  writes:
> 
>> On Tue, 15 May 2018 07:29:39 -0700, Mike McClain wrote:
>>
>> > I had gotten the impression that everything in OOP is an object but
>> > you're all saying that variables are not objects.
>>
>> Perhaps it is better to say every VALUE in Python is an object.
> 
> IMO that is better than using the term “variable”, which carries baggage
> from other languages when people try learning Python.
> 
> But not good enough. It was you, Steven (I think?) who taught me that
> using the term “value” interchangeably with “object” is problematic.

Not guilty Yer Honour! It wasn't me!


> That's because, in Python an object can remain the same object, while
> its value changes.

Indeed. But something can BE a value and HAVE a value at the same time, 
just as a class can be both a class and an instance (of the metaclass) at 
the same time.

It is true that if we consider mutable objects like lists, then the 
list's value can change as we move items in and out of the list.

But regardless of the value OF the list, we can still describe the list 
itself AS a value.

English is not optimal for discussing these concepts -- possibly no 
language is, or can be, as the concepts of identity, sameness, value etc 
are fuzzy and nebulous. If I replace the handle of my grandfather's axe, 
and then a year later I replace the head, is it still my grandfather's 
axe?

https://en.wikipedia.org/wiki/Ship_of_Theseus

Interesting if not relevant:

https://www.sciencedirect.com/science/article/pii/S1074552113001154


But I digress... we ought to distinguish between the value of a list, 
which of course may change through the list's lifetime, and the fact that 
no matter what value it has, it is still a value.

I'm not the same person I was 40 years ago, but both then and now I 
remain a person.


[...]
> Therefore, an object is not its value (otherwise, when the value
> changes, we necessarily have a different object. That's false, and so
> the equivalence is also false.)

I think you are begging the question by assuming that a change of value 
implies a new object. That's not how the words are used in standard 
English.

My house can appreciate and depreciate in value, even if I do nothing but 
occasionally remember to take out the trash... but we surely must agree 
that it is the same house, even if I replace the furniture, replace a 
broken window, repaint the living room, replace a broken tap... 


> An object is not a value; an object *has* a value. The object retains
> its identity even when its value changes.

Here you have hit on the crux of the matter. Why cannot both statements 
be true?

Webster's 1913 edition of "value" lists 10 distinct meanings for the 
noun; WordNet gives 6; the Oxford English dictionary on my desk also has 
6, and if I count sub-definitions (1a, 1b, 1c etc) I get fifteen.

Looking at the WordNet definitions, the one I think is nearest to the use 
I am making is something between numbers 1 and 4:

1: a numerical quantity measured or assigned or computed;

4: relative darkness or lightness of a color; "I establish the
   colors and principal values by organizing the painting into
   three values--dark, medium...and light"-Joe Hing Lowe

Obviously I'm not talking about the darkness or lightness of a colour 
specifically, but if we can enumerate three values "dark", "light" etc, 
we can surely enumerate a larger number of values including:

None, True, False, various strings, lists, tuples, etc...

Some of these have numerical values in the sense of 1. above, some have 
textual values, some might be considered enumerations, some are compound 
values containing other values...


>> Variables *hold* values, or if you prefer, names refer to values. But
>> since they aren't themselves values, names/variables aren't objects.
> 
> I really want that sentence to be useful for this pedagogical purpose.
> My earlier message in this thread went to some length to do something
> similar.

The distinction I wanted to make, but forgot to, was that certain things 
are *first-class values* in a language, and others are not.

In Python, all objects are first-class values, and all values are 
objects. That's not the case for all languages, where some values are not 
first-class.

https://en.wikipedia.org/wiki/First-class_citizen

But not all *things* are values at all. For loops, expressions, names, 
try...except clauses etc are "things" but they're not values at all.


> But because we only invite later confusion when the “a value is an
> object” false equivalence needs un-learning, I can't let it pass.

And I wouldn't expect anything less from you :-)

If we are looking for a single, short, plain English sentence which 
perfectly explains Python's object model using nothing but ordinary words 
whose meaning are self-evidently true and completely unambiguous, I fear 
we are doomed to be disappointed.

But it is fun to keep tr

Re: object types, mutable or not?

[Chris Angelico]

On Wed, May 16, 2018 at 4:39 PM, Steven D'Aprano
 wrote:
>
> But I digress... we ought to distinguish between the value of a list,
> which of course may change through the list's lifetime, and the fact that
> no matter what value it has, it is still a value.
>
> I'm not the same person I was 40 years ago, but both then and now I
> remain a person.

You remain a person, and you still have a value. Hmm. When did this
mailing list turn into a suicide help hotline?

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