!RE: Namedtuple problem #32.11.d
Neil Cerutti wrote, on Wednesday, June 07, 2017 10:36 AM > > On 2017-06-06, Deborah Swanson wrote: > >> I too have sometimes started with a namedtuple and then found I > >> needed to make changes to the records. I typically abandon > namedtuple > >> at this point, after only one bad experience trying to > work around my > >> choice of container. > > > > I can appreciate that reaction. > > > > Guess I'm a bit of a bulldog though (right ot wrong), and the concept > > of namedtuples is so ideally suited for the Excel spreadsheet > > conversions I'm working on, I'll keep on pushing the boundaries to see > > how they can be made to work. ;) > > The namedtuple has found a happy place in my repertoire as > the return value of functions that transform external > read-only tabular data into a convenient form for lookup. > > I agree pushing a language feature beyond its preferable use > cases is a good way to learn concepts and illuminate dark > corners of both my own skill and Python's features. I certainly have learned a lot by doing exactly that. Sometimes it isn't so much people giving the solution to a problem, though that's definitely to the good, but the alternate solutions that are proposed can also be highly instructive. > An Excel spreadsheet that represents a table of data is > fairly simple to map onto a Python dict. One nearly codeless > way is to export it from Excel as a csv file and then read it > with csv.DictReader. > > -- > Neil Cerutti csv.DictReader! I didn't know there was one! I've been thinking about how a spreadsheet could be put into a dict, but wasn't quite coming up with a good way. But a csv.DictReader would be perfect, and I imagine the keys would be the column names, which is also perfect. Thanks for the lead on csv.DictReader. I suppose if I'd known one existed it would be easy to find, but when you don't know, and you don't think of it... Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuple problem #32.11.d
Richard Moseley wrote, on Tuesday, June 06, 2017 8:16 AM
>
> On 06/06/17 13:29, Neil Cerutti wrote:
> > On 2017-06-06, Deborah Swanson wrote:
> >> I have a list of namedtuples:
> >>
> >>[{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')
> >>. . .
> >>{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')]
> >>
> >> In the first section of code, I process some of the first 10
columns
> >> (r0=v0, r1=v1,...,r10=v10), and place the results in blank columns,
> >> also in the first 10 columns.
> > I too have sometimes started with a namedtuple and then found I
needed
> > to make changes to the records. I typically abandon namedtuple at
this
> > point, after only one bad experience trying to work around my choice
> > of container.
> In a package that I'm working on that enables access natively legacy
> C-ISAM files, I've found that I need to create a form of a namedtuple
> that makes use of descriptors to access each of the fields within a
> record using attribute lookup, but to also create the record object at
> runtime using a description of the fields read from another file
(C-ISAM
> works by using offsets within a record and does not natively store a
> mapping between name and offset). I found that using a metaclass to
> store the fields in a OrderedDict enabled me to embed a namedtuple to
> return the record back to the rest of the package. The code can be
found
> in pyisam/table/record.py from
> http://github.com/rpmoseley/pyisam.git.
> The code is written for 3.x but the code path for versions before 3.6
> should work for 2.7.
Since I frequently want to work across columns and down rows, sometimes
as a step in an overall process, your metaclass sounds like an
incredible solution for those sections I need this capability for.
However, in my online course studies to date, they only covered classes
for two weeks, the last week of which was spent on inheritance. So
needless to say, my experience with classes is of the simplest kind, and
I'd never heard of metclasses before I started reading this list.
But rest assured, the functionality you describe is so potentially
useful to me that I will learn what I need to know to understand your
metaclass. But this will take some time, and I may not get to it
immediately, though I'm saving your message so I can get to it at the
first possible chance.
Thank you for letting me know about this solution, which I will remember
and I look forward to learning how to use it.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuple problem #32.11.d
Neil Cerutti wrote, on Tuesday, June 06, 2017 5:29 AM
>
> On 2017-06-06, Deborah Swanson wrote:
> > I have a list of namedtuples:
> >
> > [{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')
> > . . .
> > {Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')]
> >
> > In the first section of code, I process some of the first
> 10 columns
> > (r0=v0, r1=v1,...,r10=v10), and place the results in blank columns,
> > also in the first 10 columns.
>
> I too have sometimes started with a namedtuple and then found
> I needed to make changes to the records. I typically abandon
> namedtuple at this point, after only one bad experience
> trying to work around my choice of container.
>
> --
> Neil Cerutti
I can appreciate that reaction.
Guess I'm a bit of a bulldog though (right ot wrong), and the concept of
namedtuples is so ideally suited for the Excel spreadsheet conversions
I'm working on, I'll keep on pushing the boundaries to see how they can
be made to work. ;)
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuple problem #32.11.d
Peter Otten wrote, on Tuesday, June 06, 2017 1:31 AM
>
> Deborah Swanson wrote:
>
> > [{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')
>
> Lovely column names ;)
Not very sexy names, I agree ;)
The columns do have real names. The first 10 are friendly and
semi-friendly names, but the names for the 28 triplets are each
comprised of a root word with a prefix and a suffix, so they're quite
cryptic. Copying them all out would have overwhelmed the first half of
this message and obscured that the columns are divided into two groups,
each group needing a different programmatic approach. So I went with
simple numerically based names that permitted the use of ellipses.
But I think you knew this, and were just teasing ;)
> > Because, I can't say
> >
> > r = r._replace(getattr(r, column) = data)
>
> When r is mutable, i. e. *not* a namedtuple, you can write
>
> setattr(r, column, data)
>
> This assumes column is the column name (a string) -- and it will
overwrite
> the current value of the attribute.
I'll have to try this using recordclass instead of namedtuple. After the
import, it's only a one line change to transform namedtuple code to
recordclass code.
Change
Record = namedtuple("Record", fieldnames)
to
Record = recordclass("Record", fieldnames)
and recordclass is written so elegantly that your namedtuple code
functions exactly the same as recordclass code as it did when it was
namedtuple code. (Well, I've only tried it in this one case, but from
reading the recordclass tutorial, I think that will hold up to be true
in most if not all cases.)
So you can easily switch back and forth between them.
> If you need the current value as part of a calculation you can access
it
> with getattr(). E. g. if you want to multiply columns r.foo and r.bar
by a
> value stored in data:
>
> def update_record(record, columnname, data):
> newval = getattr(r, columnname) * data
> setattr(r, columnname, newval)
>
> columns = ["foo", "bar"]
> data = 42
>
> for record in records:
> for column in columns:
> update_record(record, column, data)
Most excellent, and I'll have to also try this. I'd never seen getattr
or setattr last time we attempted a namedtuple problem, and even though
I understand them a little better now, I still haven't made a lot of
headway in using them. This will be a good chance to see another way
they can be successfully used, so thank you.
> For immutable (namedtuple) rows this has to be changed:
>
> def updated_record(record, columname, data):
> newval = getattr(r, columnname) * data
> return r._update(**{columnname: newval})
>
> for index, record in enumerate(records):
> for column in columns:
> record = updated_record(record, column, data)
> records[index] = record
Again, most excellent, and I'll try this too. It is one of my primary
goals to learn what standard Python can do, both for it's own sake, and
so I can more fully appreciate what the packages and extensions have to
offer. So a possible solution using native namedtuple code is much
appreciated.
> There are various approaches to make this clearer. As I have a vage
memory
> of recommending `dict`s before I won't do it again...
And I'm truly sorry your recommendation of several dict solutions last
time around baffled me so profoundly. The online introductory courses in
Python that I'd taken only gave us a very cursory introduction to simple
uses of dicts, and I had no idea that they could be used in so many
complex and mysterious ways. But I've been working with dicts, and
particularly with your examples of their use. I think I have a much
better understanding of most of your examples now, but not all.
I also recall your mentioning that you would solve the previous
namedtuple problem I asked about with dicts throughout, bypassing
namedtuples altogether. I was quite intrigued with that idea, but since
I lack sufficient experience with dicts I was reluctant to ask you to
elaborate.
I suspect you are hinting at a dicts-throughout solution here, but I can
only guess what you might mean.
I would be very interested in seeing what you have in mind, if you are
so inclined. Though I think I would need some time to work with it and
understand it better before I attempted to reply.
Thank you again for your continued help with this class of problems. And
I think it would be best for me to simply take in what you have to say
and work with it for while, rather than trying to interact while my
ideas about what may be going on are still fuzzy and I'm easily
confused. Just trying to spare us both some needless frustration ;)
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Namedtuple problem #32.11.d
I have a list of namedtuples:
[{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')
. . .
{Record}(r0=v0, r1=v1,...,r10=v10,r11='',...r93='')]
In the first section of code, I process some of the first 10 columns
(r0=v0, r1=v1,...,r10=v10), and place the results in blank columns, also
in the first 10 columns.
In the second section of code, I'd like to put calculated values in
columns 11-93 (r11='',...r63=''), in which 3 columns will be calculated
28 times for each Record.
Is there a way to do this as a step in the loop:
for idx, r in enumerate(records):
. . .
(ideally I'd like to have a loop here, or a function, that would
calculate the 28 triplets
and replace their empty namedtuples with their calculated
values,
but this is what I've failed to successfully do.)
I've tried writing a function, to either calculate and write 1) all 28
triplets, 2) one triplet, or 3) one column at a time, that would be
called in the body of the main loop.
The general form of this function has been:
def savedata(Records, row, column, data):
r = Records[row]
col = getattr(r, column)
r = r._replace(col = data)
but in every case I've tried this, it has failed.
Because, I can't say
r = r._replace(getattr(r, column) = data)
because that gets "can't assign to a function call".
And while col ( = getattr(r, column) ) holds the correct value before
r = r._replace(col = data)
all I get for r.column after the ._replace is an empty string, and I
have no idea how that happens.
I'm about to rewrite to process first 10 columns as namedtuples, and
then unroll the namedtuples into a list of lists, and process the 28
triplets in two for loops.
That will work, but I'm wondering if anyone can suggest a way to make my
function, or one that accomplishes the same task, so as to preserve the
namedtuples, and avoid the need for a second, dual nested loop to finish
the second part of the problem.
(Note: I have the same dilemma using recordclass instead of
namedtuples.)
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Thursday, June 01, 2017 1:15 AM > > Deborah Swanson wrote: > > I have already offered to do whatever you would like me to > do on this > > system > > If you wouldn't mind, I'd like to see the output from this command: > > python -m ensurepip > > -- > Greg The rest of that sentence was something like later, when I have Python in Linux and don't need this sytem anymore. I've tried ensurepip 2 or 3 times, with different unsuccessful outcomes each time. I really am done trying to fix this installation, and I just hope it holds together for PyCharm's use as long as I need it to. Couple months, I think. And if I don't touch it, should be ok. Now please, can we be done with this for now? Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Thursday, June 01, 2017 1:12 AM > > Deborah Swanson wrote: > > Why do you care so deeply what pip does on an operating > system that is > > no longer supported? > > Being pipless is a sufficiently distressing fate that we'd > like to help, even if you didn't explicitly request it. > > Particularly since it seems like such an unnecessary one, > because installing pip shouldn't require any kind of compiler > on any version of any operating system, supported or > otherwise. So the fact that it apparently does on your system > is very puzzling, and some of us would like to solve that puzzle. > > -- > Greg That's nice, but as I've said, the problem can be solved by reinstalling Anaconda3 and PyCharm. Not fun or easy, but at least the outcome would be known if I really needed pip, which I won't for quite awhile. Honestly, this installation of Anaconda3 is so unstable it behaves differently everytime I try to do something with it. Better to leave well enough alone right now. I really need what little usable time I have making progress with Python, and I should be a lot healthier in a few months. And I'd rather spend the downtime then getting my good computer up and running, and Python on Linux again. Then this problem vanishes. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Thursday, June 01, 2017 12:59 AM > > Deborah Swanson wrote: > > I got one suggestion that I could just copy the files to "the > > appropriate directories", > > That was me, but I've just had a look at the source, and it > seems the core functionality is implemented in C, so scrub that idea. Yes, memoryslots.c is core functionality, and I was just going to have to fake it if the compiled file needed more than just being dropped into Site Packages. > But all is not lost. I've found this: > https://pypi.python.org/pypi/namedlist "Similar to namedtuple, but instances are mutable." It's all pure Python -- I checked this time! -- so you shouldn't have any trouble installing it. In fact it's just a single source file, namedlist.py. Put that in your site-packages folder and you should be good to go. -- Greg Thanks Greg! I just ran into another wall, unsolvable by any methods I've come up with yet, so I'm trying to unroll the namedtuples into a list of lists, and that turns out to be trickier than you'd think too. I'll give namedlist a try, seems the PyPi people have seen that hole in namedtuples' functionality and have worked on some alternatives. Spectacular! Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
You are correct. My health is at it's lowest ebb in many years. Quite possibly I forgot that I'd deleted the post with the traceback instead of sending it because I was overwhelmed with pain at the time, and with the difficulties in doing even the smallest things. However, in your opening quote of what I said, I still meant that "it" meant Anaconda3 and/or Python 3.4.3 and/or pip itself. The attempt to install Visual Studio 2015 occurred during my attempt to upgrade pip. Which component of the installation exactly did it, I don't know, all I know is that it happened and that's when it broke. I assumed you all would know that installations of this type have many components, but once again I underestimated you. I suppose you can impale me for writing quickly, without spelling out what each and every pronoun stands for. I didn't realize that the crime I'm being burned at the stake for was/is impugning the mighty pip until this evening. Sorry, but after I said that no one could say anything more that would be useful (and I was right) I'd archived the thread until someone revived it by addressed me personally. And that turned out to be for my imaginary presence in a discussion I was ignoring. So good job. Are you proud of the mess you've made? Oh, and I don't suppose anyone knows how to build recordclass from source, which was my original question. Deborah > -Original Message- > From: Python-list > [mailto:python-list-bounces+python=deborahswanson.net@python.o > rg] On Behalf Of breamore...@gmail.com > Sent: Tuesday, May 30, 2017 5:06 PM > To: python-list@python.org > Subject: Re: How to install Python package from source on Windows > > > On Tuesday, May 30, 2017 at 11:32:46 PM UTC+1, Deborah Swanson wrote: > > I really don't get it how all of you have latched onto this > idea that > > I said pip tried to install Visual Studio. I said it > happened when I > > tried to upgrade pip, and I agreed with someone else who > wondered if > > it might have been Anaconda3 that did it. > > > > Quoting you Wed May 24 20:18:03 EDT 2017 "When I tried to > upgrade pip it failed because it could neither find nor > install Visual Studio 2015." That is certainly strong enough > in my book for people to latch onto an idea. I simply think > that you are mistaken, in just the same way that you've > admitted previously in this thread that you believe that > you've done something, but actually haven't. I put that down > to your poor health, something with which I can sympathise, > as I suffer from a combination of anxiety, depression, > chronic fatigue syndrome, insomnia, autism and, last and > thankfully least, diplopia. > > Kindest regards. > > Mark Lawrence. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
I really don't get it how all of you have latched onto this idea that I said pip tried to install Visual Studio. I said it happened when I tried to upgrade pip, and I agreed with someone else who wondered if it might have been Anaconda3 that did it. May I remind you that I wasn't the one to reignite this tempest in a teacup, I've simply tried to answer your questions. > -Original Message- > From: Paul Moore [mailto:p.f.mo...@gmail.com] > Sent: Tuesday, May 30, 2017 3:03 PM > To: pyt...@deborahswanson.net > Cc: python-list@python.org > Subject: How to install Python package from source on Windows > > > On 30 May 2017 at 21:27, Deborah Swanson > wrote: > > I have already offered to do whatever you would like me to > do on this > > system - after I'm up and running on Linux. I need a functioning > > PyCharm on this system until that happens. > > OK. I'm not sure I care enough to remind you, but if you want > to follow up at that point, then that's great. Can you start > by proving your assertion that pip is trying to install Visual Studio? > > > Please accept my word that the attempt to upgrade pip broke when it > > tried to install Visual Studio 2015, and I wouldn't even > have known to > > say that's what happened if I hadn't seen it in the > traceback. Quite > > possibly it wasn't supposed to do that, but I won't be able to > > reproduce that traceback until I no longer need Python3 running on > > this system. > > I can't accept that - because there's no code that's run by > "python -m pip install -U pip" that would try to install > Visual Studio. If nothing else, how would it know where to > download it from? If that's not the command you used to > upgrade pip, then can you remind me (if you've already said) > or say what command you *did* use? If you can't tell me what > that command was, then can you accept my word that "python -m > pip install -U pip" cannot have been the cause of an attempt > to install Visual Studio 2015? > > > I'm not sure what it is that you think we disagree on. > > Well, the above for a start. But also, that it's worth my > while caring about this. I take it quite personally that you > keep insisting that pip can or would attempt to install > Visual Studio, without backing up that assertion. As far as I > can tell, you think that i shouldn't. > > Anyway, this is getting nowhere, so I won't comment further. > > Paul > -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
I never said it was pip's fault, so there's nothing for you to accept my word on. It could easily have been something that Anaconda3 did in the process of upgrading pip. But you're just trying drag this on as long as possible by manufacturing an argument where there is none. > -Original Message- > From: Python-list > [mailto:python-list-bounces+python=deborahswanson.net@python.o > rg] On Behalf Of Chris Angelico > Sent: Tuesday, May 30, 2017 1:35 PM > To: python-list@python.org > Subject: How to install Python package from source on Windows > > > On Wed, May 31, 2017 at 6:27 AM, Deborah Swanson > wrote: > > Please accept my word that the attempt to upgrade pip broke when it > > tried to install Visual Studio 2015, and I wouldn't even > have known to > > say that's what happened if I hadn't seen it in the > traceback. Quite > > possibly it wasn't supposed to do that, but I won't be able to > > reproduce that traceback until I no longer need Python3 running on > > this system. > > That's what we are not wanting to do - to merely accept your > word that something so utterly illogical as "Python insists > on installing VS2015" should be happening. We want > tracebacks, not assertions. So no, I won't accept your word > that this is pip's fault. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Re: How to install Python package from source on Windows
I have already offered to do whatever you would like me to do on this system - after I'm up and running on Linux. I need a functioning PyCharm on this system until that happens. Please accept my word that the attempt to upgrade pip broke when it tried to install Visual Studio 2015, and I wouldn't even have known to say that's what happened if I hadn't seen it in the traceback. Quite possibly it wasn't supposed to do that, but I won't be able to reproduce that traceback until I no longer need Python3 running on this system. I'm not sure what it is that you think we disagree on. Deborah > -Original Message- > From: Paul Moore [mailto:p.f.mo...@gmail.com] > Sent: Tuesday, May 30, 2017 12:57 PM > To: pyt...@deborahswanson.net > Cc: python-list@python.org > Subject: Re: How to install Python package from source on Windows > > > On 30 May 2017 at 20:15, Deborah Swanson > wrote: > > Why do you care so deeply what pip does on an operating > system that is > > no longer supported? > > Sigh. I guess we just have to agree to differ. > > > And I'm sorry you're upset that pip is not behaving as > expected, but > > please remember that this happened in an unstable build of > Anaconda3 > > on an unsupported operating system. > > In my experience, many people have to use pip on systems that > I'd rather not support. And technically, pip still supports > the setup you have (in theory - it's a supported Python > version,and that Python version's supported on your OS, etc). > But whatever. > > Paul > -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Why do you care so deeply what pip does on an operating system that is no longer supported? Anaconda3 Python 3.4.3 just barely installed on XP SP2, and it's given me nothing but trouble since. I don't need any help with it. As for my original question about installing recordclass from source, I got one suggestion that I could just copy the files to "the appropriate directories", and nothing but silence when I said that I could guess where to put the .py files but wasn't sure, and memoryslots.c needs to be compiled before it can be copied anywhere. I'm pretty sure I can compile it with Tiny C and resume guessing where the files go, etc. on my own. That was my last request for help, and I certainly don't recall offering any services to satisfy the inquiries of where this thread ended up. I'm sorry, but any other assumptions that were made about what I was there for were simply in error. And I'm sorry you're upset that pip is not behaving as expected, but please remember that this happened in an unstable build of Anaconda3 on an unsupported operating system. Deborah > -Original Message- > From: Paul Moore [mailto:p.f.mo...@gmail.com] > Sent: Tuesday, May 30, 2017 11:01 AM > To: pyt...@deborahswanson.net; python-list@python.org > Subject: How to install Python package from source on Windows > > > On 30 May 2017 at 16:56, Deborah Swanson > wrote: > > I'm sorry people on the list somehow got the idea I was asking for > > help with this. Originally I only asked how to build > recordclass from > > source, and apparently I made the mistake of chiming in with my > > experiences with Anaconda3, Python 3.4.3, on XP SP2, when the > > conversation turned to Python's use of Visual C++ and > Visual Studio in > > the installation of new builds. I thought you might find my > > experiences interesting, but at no point did I ask for help > that I'm > > aware of. If I did somehow give that impression it was a > > miscommunication with no intentional asking for help. > > It certainly wasn't clear to me that once you'd got beyond > the installation of recordclass, you were not asking for help. > > From my perspective, as one of the authors of pip, you seemed > to be hitting a number of issues, all of which I would > consider to be pretty serious problems with the usability of > pip. And I'd want to get to the bottom of them so I could get > them fixed for other users, as much as for yourself. > > 1. That pip (or maybe Python?) attempts to install Visual > Studio. If true, this would be a pretty serious security > issue, as you clearly didn't intend to request an install of > VS. 2. That upgrading pip via "python -m pip install -U pip" > didn't work. That command's already far messier than we would > like, so we take any further issues making it hard for people > to keep up to date with pip pretty seriously. 3. That you > even thought that pip should want to install VS - which is a > problem with our documentation. > > Obviously, you aren't required to do any diagnosis beyond > that needed to resolve your own issues, but the fact that you > were still participating in the thread seemed like you were > willing to help - so people asked questions to try to pin > down the issue. Part of that is trying to reproduce your > problems, and identify what's particular about your case, so > understanding details of your system is important. Things got > a little out of hand at this point because it appears that > you got the impression that people were criticising your > choice of system. I don't think they were, but I didn't read > the thread in full (and I know that it's sometimes easy to > see such criticism - as a Windows user myself, I'm prone to > over-reacting to "you wouldn't get that with Linux" types of > comment!) Nevertheless, I don't recall seeing you ever saying > that you'd resolved your issues to your satisfaction, and you > didn't think that the problems you'd mentioned were going to > happen to anyone else, as they were specific to your setup. > Maybe I missed it (it's a long thread and I did skim rather > than reading in detail) - apologies if that was the case. > > > My strong suspicion is that the reason I'm actually seeing failed > > attempts to install Visual C++ and Visual Studio 2015 while none of > > you others are seeing any use of Visual C++/Studio is > because it shows > > up in my tracebacks when it fails. In an XP SP3 or later > Windows these > > minor installations would succeed and the user would never > know th
RE: How to install Python package from source on Windows
> -Original Message- > From: Deborah Swanson [mailto:pyt...@deborahswanson.net] > Sent: Tuesday, May 30, 2017 8:57 AM > To: 'Paul Moore' > Subject: RE: How to install Python package from source on Windows > > > I'm sorry people on the list somehow got the idea I was > asking for help with this. Originally I only asked how to > build recordclass from source, and apparently I made the > mistake of chiming in with my experiences with Anaconda3, > Python 3.4.3, on XP SP2, when the conversation turned to > Python's use of Visual C++ and Visual Studio in the > installation of new builds. I thought you might find my > experiences interesting, but at no point did I ask for help > that I'm aware of. If I did somehow give that impression it > was a miscommunication with no intentional asking for help. > > Any attempts to "fix" my setup only destabilize my system and > make something worse. What I have works to run Python code in > PyCharm, and until I get a Linux system up and running I have > no intention of messing anymore with what I've got. And I > certainly don't appreciate all the insinuations that I'm > stupid or lazy. I'm simply caught in a precarious situation > that I'm making the best of. 3.4.3 was the last Anaconda > build of Python that would install on XP SP2 at all, and it > came with no guarantees. I suspect it was my expertise with > XP SP2 that I cajoled a successful installation out of it and > it was tricky to get that to run in PyCharm. > > My strong suspicion is that the reason I'm actually seeing > failed attempts to install Visual C++ and Visual Studio 2015 > while none of you others are seeing any use of Visual > C++/Studio is because it shows up in my tracebacks when it > fails. In an XP SP3 or later Windows these minor > installations would succeed and the user would never know > they occurred, or perhaps they aren't even needed on later > versions of Windows. Unfortunately I didn't keep my > tracebacks, having thought that they were no longer of any > interest to the group at the time I had them, and I'm > unwilling to destabilize my system and risk any further loss > of functionality in any more attempts to reproduce them. > > Anaconda3 and XP SP2 do no get along well. I will be more > than happy to run any experiments and recreations you please > after I have Python 3.6 running well in Linux. But until then > I need to go on surviving with what I've got. > > I hope I am being perfectly clear now. But I certainly wasn't > willing to go up against an angry mob intent on "helping" me > or satisfying their curiosity at my my expense (or whatever > they wanted), when I neither wanted nor needed (nor was aware > of any explicit request for) any help. It is what it is, and > I'm progressing just fine with what I've got. > > Deborah > > > -Original Message- > > From: Python-list > > [mailto:python-list-bounces+python=deborahswanson.net@python.o > > rg] On Behalf Of Paul Moore > > Sent: Tuesday, May 30, 2017 2:43 AM > > To: python-list@python.org > > Subject: Re: How to install Python package from source on Windows > > > > > > On Thursday, 25 May 2017 22:32:56 UTC+1, Deborah Swanson wrote: > > > This is my last reply on this thread to anything to do with XP SP2 > > > (observations in XP SP3 do not apply) or Visual Studio. > > I've answered > > > all of the questions, some of them multiple times. Please > > reread the > > > thread if you have more questions. > > > > You have repeatedly stated "Python attempts to install Visual > > Studio" but have never provided a log showing that, or any > > evidence that we could use to help understand why this is happening. > > > > Everyone here has repeatedly pointed out that Python > > shouldn't ever do what you're saying it does, and various > > people have stated that they've tested and confirmed this is > > the case. Sometimes they've used systems other than the > > version of XP that you have, but that's not (as far as anyone > > can tell) relevant. Nevertheless, you've dismissed these > > demonstrations - often with claims of "XP Bashing" which I've > > seen no evidence of in this thread. > > > > It seems to me that your Python installation has somehow > > ended up being configured in a non-standard manner (I'm > > bending over backwards here to avoid triggering a "you're > > bashing XP" reaction here -
RE: How to install Python package from source on Windows
Since none of you have XP SP2 with Anaconda3 Python 3.4.3, to either confirm or deny my results, and I no longer have the message with the traceback showing what happened, nothing anybody says at this point matters wrt to what happens in XP SP2. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
breamore...@gmail.com wrote, on Thursday, May 25, 2017 3:23 PM > > On Thursday, May 25, 2017 at 10:32:56 PM UTC+1, Deborah Swanson wrote: > > > Michael Torrie wrote, on Thursday, May 25, 2017 1:57 PM > > > > I didn't see a traceback where you tried to upgrade pip > to 9.0.1. > > > > It's a long thread. You just didn't find it. > > > > You've never attempted to upgrade pip that I can see. You > were invited to do so > https://www.mail-archive.com/python-list@python.org/msg426173. html but apparently didn't bother. Kindest regards. Mark Lawrence. I apologize. I wrote it up, with the traceback, but the group had moved on and I decided not to send it. Unfortunately I deleted that message and now I no longer have a pip to run python -m pip install --upgrade pip So I can't make another traceback. But the upgrade attempt did uninstall the old pip, which is why I don't have one now, and it died trying to install Visual Studio 2015. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
MRAB wrote, on Thursday, May 25, 2017 2:46 PM > > On 2017-05-25 21:24, Chris Angelico wrote: > > On Fri, May 26, 2017 at 6:16 AM, Deborah Swanson > > wrote: > >>> Anyway I can confirm that VS is not required for installing and > >>> using pip on XP, nor is it required for recordclass, since it's > >>> available in wheel form. > >> > >> See my tracebacks earlier in this thread. You confirmed > that it works > >> in XP SP3, only. > > > > Doesn't matter whether VS works on SP3 but not SP2 - the point was > > that pip works without VS. > > > Here's a question: does Anaconda have a special build of Python, or is > it a standard Python bundled with extra stuff? I'm not sure, and it's an excellent question. Anaconda stopped installing Python on XP at 3.4.3. python.org doesn't install 3.5 on XP, but I don't know which build was the last one that would. Anaconda and python.org do have completely separate and different build processes, but I suspect the incompatibility for XP SP2 in both has to do with failed attempts to install Visual Studio 2015. I've seen it too many times not to be fairly sure of that. XP SP3 evidently does work, if Michael Torrie had no problem. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
> Michael Torrie wrote, on Thursday, May 25, 2017 1:57 PM > > I didn't see a traceback where you tried to upgrade pip to > > 9.0.1. It's a long thread. You just didn't find it. This is my last reply on this thread to anything to do with XP SP2 (observations in XP SP3 do not apply) or Visual Studio. I've answered all of the questions, some of them multiple times. Please reread the thread if you have more questions. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Michael Torrie wrote, on Thursday, May 25, 2017 1:57 PM > > On 05/25/2017 02:16 PM, Deborah Swanson wrote: > >> I just fired up my Windows XP SP3 virtual machine, which has > >> no development tools whatsoever on it (no VS, nothing). I > >> installed 32-bit Python 3.4 from the official python.org > >> download. Then I did the pip > >> upgrade: > > > > Yes XP SP3 can install Visual Studio 2015. No, XP SP2 cannot. > > Huh? What are you talking about? Where are you reading that > I installed Visual Studio? I never had any version of VS > installed, nor was any needed. Python will attempt to install Visual Studio, and it fails on XP SP2. > > See my tracebacks earlier in this thread. You confirmed > that it works > > in XP SP3, only. > > I didn't see a traceback where you tried to upgrade pip to > 9.0.1. Did you post that? Anyway, it also appears you're > not using the stock Python 3.4 from python.org, so perhaps > whatever version of Python you're using has been modified in > some way. Perhaps the Anaconda folks have a forum or mailing > list that may be more helpful. > > The main point, however, is that upgrading pip and installing > recordclass does not require visual studio at all, on any OS > (including > XP) where a recordclass wheel is available. That was my point. > > As to what I confirmed, you were going on and on about how > Pip somehow requires Visual Studio to be installed, when in > fact it doesn't. As stock Python 3.4 can apparently run on > SP2, pip will run also, without visual studio. > > Though at the risk of drawing your ire, most programs that > run on XP require SP3. I'm a bit surprised that Python 3.4 > will even run at all on SP2. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Michael Torrie wrote, on Thursday, May 25, 2017 12:12 PM > > On 05/25/2017 10:09 AM, Deborah Swanson wrote: > > Could be, maybe it's something they do for every > installation, whether > > it will use it or not. But it always breaks when it can't install > > Visual Studio. Upgrade pip does run and it works up to that > point. It > > gets as far as uninstalling the old pip, but then there's no way to > > get any pip reinstalled. > > I just fired up my Windows XP SP3 virtual machine, which has > no development tools whatsoever on it (no VS, nothing). I > installed 32-bit Python 3.4 from the official python.org > download. Then I did the pip > upgrade: Yes XP SP3 can install Visual Studio 2015. No, XP SP2 cannot. Please read earlier in this thread for the details. > C:\Python34>python -m pip install -U pip > Collecting pip > Downloading pip-9.0.1-py2.py3-none-any.whl (1.3MB) > 100% || 1.3MB 137kB/s > Installing collected packages: pip > Found existing installation: pip 7.1.2 > Uninstalling pip-7.1.2: > Successfully uninstalled pip-7.1.2 > Successfully installed pip-9.0.1 > > C:\Python34>python -m pip install recordclass > Collecting recordclass > Downloading recordclass-0.4.3-cp34-cp34m-win32.whl > Installing collected packages: recordclass > Successfully installed recordclass-0.4.3 > > > I'm not sure what's wrong with your python installation but > it has nothing to do with Windows XP or Visual Studio. It > might help if you cut and paste the exact errors you are > seeing. Also did you mention before whether you're running > the standard Python 3.4 package from python.org or are you > running some third-party system? I thought you mentioned > something about anaconda. Please read earlier in this thread if you are still confused. Previous of my posts also contain complete tracebacks. > Anyway I can confirm that VS is not required for installing > and using pip on XP, nor is it required for recordclass, > since it's available in wheel form. See my tracebacks earlier in this thread. You confirmed that it works in XP SP3, only. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Thursday, May 25, 2017 12:47 AM > > On Thu, May 25, 2017 at 4:57 PM, Deborah Swanson > wrote: > > Oh, what bliss it must be to run on a system that hasn't > been declared > > a pariah by everyone and his dog. (But yet it covers all > the essential > > bases quite nicely.) > > > > I tried ensurepip, but it also wants to install a recent version of > > Visual something-or-other, and it breaks and dies when it can't. So > > pipless I will be for the near term. > > > > Pip may be pure Python, but it seems everything that wants to do > > anything with pip wants a recent version of Visual > something-or-other > > to do it with. > > I'm beginning to wonder if maybe there's a non-standard file > in the installation that's getting imported ahead of the > standard library, and THAT is what's looking for MSVS. > > ChrisA Could be, maybe it's something they do for every installation, whether it will use it or not. But it always breaks when it can't install Visual Studio. Upgrade pip does run and it works up to that point. It gets as far as uninstalling the old pip, but then there's no way to get any pip reinstalled. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Wednesday, May 24, 2017 10:58 PM > > Deborah Swanson wrote: > > > So now I'm pipless. > > You should be able to get it back using > > python -m ensurepip > > BTW, I don't know why upgrading pip would fail due to lack of > Visual Studio. That shouldn't be able to happen, because pip > is pure Python. > > -- > Greg Oh, what bliss it must be to run on a system that hasn't been declared a pariah by everyone and his dog. (But yet it covers all the essential bases quite nicely.) I tried ensurepip, but it also wants to install a recent version of Visual something-or-other, and it breaks and dies when it can't. So pipless I will be for the near term. Pip may be pure Python, but it seems everything that wants to do anything with pip wants a recent version of Visual something-or-other to do it with. I am planning to build recordclass by hand, as you outlined, after I finish the pure namedtuples Excel sheet conversion I'm working on, and a tkinter display with postgre permanent data storage for it. The only reason building recordclass by hand might fail is if a file or files needs to be dropped somewhere that I can't anticipate or figure out. But I'd like to see what recordclass can do, I just need this one spreadsheet's worth of code working asap first, with as little fuss as possible. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote, on Wednesday, May 24, 2017 6:32 PM > > On Thu, May 25, 2017 at 12:18 AM, Deborah Swanson > wrote: > > > > When I tried to upgrade pip it failed because it could neither find > > nor install Visual Studio 2015. > > Installing and upgrading pip does not require a C compiler. > > > So now I'm pipless. Read the thread if you want to know why I don't > > have and can't (and won't) install Visual Studio 2015. > > VS 2015 is the wrong version for Python 3.4 anyway. You would > need VS 2010. However, you don't need it in this case. You > just need the latest pip. > > For packages that don't have wheels available on PyPI, you > can often find an unofficial build on Christoph Gohlke's site > [1]. He still builds and distributes wheels for Python 3.4, > but I don't know for how much longer. > > [1]: http://www.lfd.uci.edu/~gohlke/pythonlibs Ok, I'm done with you guys who don't have a clue what happens to users of operating sytems forced at gunpoint to die. Well, that's the attempt anyway, but both me and my operating system are real hard to kill. I'm dealing with it, so please, no more advice to use fancy toys that don't work on XP. And hopefully no more XP bashing because it's my only choice right now, and I'm not going to turn off my computer and twiddle my thumbs all day, especially when there's tons of python to keep learning and using every day, right here on Windows XP. I spent 6 hours today on a very difficult project, and I'm not going to shut it all down and quit because some people apparently think that's the only alternative to upgrading to some other system, and I can neither afford the time or money to do that right now. And I don't need to. I know XP inside and out, having tested it at Microsoft for 2+ years, and used it intensively for the last 15 years. Actually, any more XP bashing and replying posts will be immediately deleted on my computer without reply from me. (Not saying that you or Paul did that, just warning anyone who wants to use this opportunity to jump on the XP beatdown wagon. And I keep track and keep names, so I'll know you if you ever reply to me again about anything.) Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Paul Moore wrote, on Wednesday, May 24, 2017 5:53 AM > On Monday, 15 May 2017 22:42:22 UTC+1, Deborah Swanson wrote: > > MRAB wrote, on Monday, May 15, 2017 12:44 PM > > > > > > On 2017-05-15 13:52, eryk sun wrote: > > > > On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson > > > > wrote: > > > >> > > > >> Where did you find > recordclass-0.4.3-cp34-cp34m-win32.whl? There > > > >> weren't any win32 builds on > > > https://pypi.python.org/pypi/recordclass. > > > > > > > > It's in the > > > middle of the file list: > > > > > > > > recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python > Wheel cp34 > > > > 2017-04-17 17KB > > > > > > > > Maybe you're looking at a cached page in your browser? But that > > > > doesn't explain why pip doesn't see it. > > > > > > > >> Maybe I can find an earlier 3 build that won't demand > Visual C++. > > > > > > > > The wheel doesn't need a compiler. It has an ABI tag because it > > > > already includes the compiled extension module. > > > > > > > I used pip to install into Python 3.4 (32-bit) from PyPI. > It fetched > > > "recordclass-0.4.3.tar.gz" and compiled it instead of fetching > > > "recordclass-0.4.3-cp34-cp34m-win32.whl". > > > > > > Why? > > > > Excellent question, though I have no clue what the answer is. > > > > > Come to think of it, what's that "cp34m" in the name? I don't have > > that > > > in the regex module's wheels, I have "none" instead. > > > > Another excellent question. "cp" in "cp34m" might stand for > C++, but > > if so, what's the rest of it mean? Or maybe "CPython 3.4" plus "m" > > (whatever "m" stands for)? > > > > What's "the regex module's wheels"? I certainly don't know, > though I > > know vague outines of what "regex" and "wheel" are. > > > > > Rename "recordclass-0.4.3-cp34-cp34m-win32.whl" to > > > "recordclass-0.4.3-cp34-name-win32.whl". > > > > > > With the new name, it installs and seems to work! > > > > Most excellent and I will try it. > > I don't know whether you solved your issue, but in case you > didn't, the problem is that the "cp34m" part of the name > indicates the "ABI" used in the extension (roughly, how the C > part of the code links to the Python interpreter). Older > versions of pip (such as the one shipped with Python 3.4, > which is itself a bit old now) didn't recognise that tag, and > so won't install that wheel. > > The best way to fix this is to upgrade the copy of pip you have, using > >python -m pip install --upgrade pip > > When you do that, you'll get a version of pip that recognises > the "cp34m" tag, and "pip install recordclass" should then just work. > > Hope this helps, > Paul Ah, but. When I tried to upgrade pip it failed because it could neither find nor install Visual Studio 2015. Unfortunately it had uninstalled pip before it found that problem. So now I'm pipless. Read the thread if you want to know why I don't have and can't (and won't) install Visual Studio 2015. Looks like I'll have to reinstall Anaconda3 if I need the old pip before I get resituated in Linux, but that's a major pain in inself because it won't reinstall in the same directory, especially since I could also end up having to reinstall Pycharm (and risk losing all my code histories) too. Bleah. Hope I don't need pip in the immediate future, old pip or new. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Survey: improving the Python std lib docs
> -Original Message- > From: Python-list > [mailto:python-list-bounces+python=deborahswanson.net@python.o > rg] On Behalf Of Gregory Ewing > Sent: Thursday, May 18, 2017 5:00 PM > To: python-list@python.org > Subject: Re: Survey: improving the Python std lib docs > > > Deborah Swanson wrote: > > > somenamedtuple._replace(kwargs) > > > > Return a new instance of the named tuple replacing specified > > fields with new values: (Examples > > box)---| > > |>>> > > | > > | > > | > > |>>> p = Point(x=11, y=22) > > | > > |>>> p._replace(x=33) > > | > > |Point(x=33, y=22) > > To someone who has some basic Python knowledge about what > keyword arguments are, that's actually pretty clear. What > it's saying is that any of the namedtuple's attribute names > can be used as a keyword argument to the _replace method. > > Namedtuple is something of a special case, because it doesn't > have a fixed set of acceptable keyword args. Most things do, > and there should be something somewhere in the docs > indicating what they are. Note that you may need to consult > docs for base classes to get the full picture, since e.g. > constructors often pass any keyword args they don't > understand on to their base class constructor. I'm getting a clearer picture, and even though it might not be as cleanly straightforward as using recordsclass, I think it would be a good learning experience to use "somenamedtuple._replace(kwargs)" in a context of my own devising, rather than just copying out code given for a different problem from someone else. Besides, I need to compile memoryslots.c to make a usable recordsclass module, and I haven't successfully compiled a C program outside of Visual Studio yet(and that was a couple decades ago). So I'm going to see if I can really understand kwargs in a namedtuple context first. It will be good to have a bag of tricks to tackle all my Excel spreadsheet conversion-to-Python and new-from-scratch projects with. I'm saying goodbye to Microsoft Excel, but I want to take all my work and ideas with me. And who knows, maybe I'll have some templates and tutorials to contribute for others who'd like to do the same. > > Now, I understood what he meant from the context of the problem he was > > helping me with, but, how in the world would I have gotten that > > possible use of somenamedtuple._replace(kwargs) from the blurb and > > examples in the docs? > > From knowledge about keyword arguments in general, > exrapolation from the example, and following logic. > > I know that's probably not a very helpful answer, but the > reason it seems so obscure to you now is because you don't > have all of the basic Python knowledge that the docs assume > the reader has. If you come back to the same docs later when > you do have that knowledge, you will see it all more clearly. Oh, I think I see what you mean now. But I'm sure glad I've had this list to talk to, or I'd never have figured it out from scratch on my own. > > If there's a tutorial somewhere on kwargs in general, what specific > > types of kwargs there are, what special operators can be specifed for > > them and how the kwargs are used, it would be very helpful to have > > that tutorial referenced in a footnote-link next to kwargs whenever > > kwargs is part of a function specification. > > This is all general knowlege about the Python language that > you can't expect the reference documentation to point out in > relation to every function and method. No, perhaps not. I was frustrated by not being able to see and understand what I needed to know from the docs, but maybe more in depth tutorials for beginners, and some kind of pointers to them, would fill that gap more effectively. > > I have an item on my todo list to google "python kwargs", but it keeps > > getting pushed deeper and deeper down my list because I have so little > > hope that it will turn up anything useful. > > I strongly encourage you to do it sooner rather than later, > because you'll gain some important foundational knowledge > that's vital for understanding many things you'll see in > Python code and Python docs. > > -- > Greg I may do that Google search when I get to it, but I've learned a lot right here. Maybe enough, but Ill have to work with what I now know to see that. Thanks very much, Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Survey: improving the Python std lib docs
justin walters wrote, on Thursday, May 18, 2017 8:09 AM > To: python-list@python.org > Subject: Re: Survey: improving the Python std lib docs > > So, args can be treated as a simple (named)? tuple or a > simple dictionary. `*` unpacks a list or tuple and `**` > unpacks a dictionary. I'm sure it's a lot more nuanced than > this, but for practical reasons, the above explanation has > never failed me. > > I hope I didn't miss the entire point of the thread. Someone > needed help with `**kwargs` right? I think I was mainly the one who wasn't sure what "**kwargs" are, and this, plus your examples I snipped, and bits and pieces I already knew, neatly pulls it all together. Think I have a good working idea of it now, so thanks! Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Survey: improving the Python std lib docs
Michael Torrie wrote, on Wednesday, May 17, 2017 3:11 PM
>
> On 05/17/2017 02:31 PM, Ned Batchelder wrote:
> > Can you give an example of such a method? Often, that signature is
> > used because there is no pre-conception of what the arguments might
> > be.
>
> I'm not sure if this afflicts the standard library, but in my
> own code, since Python doesn't support constructors with
> different signatures, you pretty much have to rely on kwargs
> with __init__() to handle different permutations of
> construction arguments. Not that we don't know what the
> arguments might be, we just don't know which of them we'll
> have to deal with. Maybe the standard library is better
> designed than my own code, but I find I have to implement
> __init__(self, **kwargs) all the time.
While I can respect and appreciate your specialized interest in specific
kwargs, and I read in other's posts that help()'s display of kwargs is
conditional on several things, I really want to reiterate and clarify my
beginner's request.
I know of several functions I've used without any *args or **kwargs
because I had no clue from the docs what they might be. And, I know of
one function now, from posts in this list, which takes kwargs, but I
only know one application of one possible kwarg in this function because
one member of this list, Peter Otten, used it in a suggestion he gave
me.
This is all there is in the docs for that function:
somenamedtuple._replace(kwargs)
Return a new instance of the named tuple replacing specified fields
with new values:
(Examples
box)---|
|>>>
|
|
|
|>>> p = Point(x=11, y=22)
|
|>>> p._replace(x=33)
|
|Point(x=33, y=22)
|
|
|
|>>> for partnum, record in inventory.items():
|
|... inventory[partnum] =
record._replace(price=newprices[partnum], |
| timestamp=time.now())
|
|---
|
>From this doc entry's example, I (sort of) get that x is a keyword arg
that is to be equal to 33 for any use of p._replace() in the code
following, until
p._replace(kwarg) is respecified, or the code ends. So the response from
Python shows me that p has transformed to the Point(x=33, y=22). A
trivial example that doesn't begin to hint at the poential powers of
this kwarg.
The inventory[partnum] example is also quite trivial compared to the
kwarg use that Peter showed me.
When I asked him for an explanation, this is what I and he he said:
Deborah Swanson wrote:
> I know it's your "ugly" answer, but can I ask what the '**' in
>
> fix = {label: max(values, key=len)}
> group[:] = [record._replace(**fix) for record in group]
>
> means?
(Peter wrote)
d = {"a": 1, "b": 2}
f(**d)
is equivalent to
f(a=1, b=2)
so ** is a means to call a function with keyword arguments when you want
to
decide about the *names* at runtime. Example:
>>> def f(a=1, b=2):
... print("a =", a)
... print("b =", b)
... print()
...
>>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
... f(**d)
...
a = 10
b = 2
a = 1
b = 42
a = 100
b = 200
Starting from a namedtuple `record`
record._replace(Location="elswhere")
creates a new namedtuple with the Location attribute changed to
"elsewhere",
and the slice [:] on the left causes all items in the `groups` list to
be
replaced with new namedtuples,
group[:] = [record._replace(Location="elsewhere") for record in group]
is basically the same as
tmp = group.copy()
group.clear()
for record in tmp:
group.append(record_replace(Location="elsewhere"))
To support not just Location, but also Kind and Notes we need the double
asterisk.
Now, I understood what he meant from the context of the problem he was
helping me with, but, how in the world would I have gotten that possible
use of somenamedtuple._replace(kwargs) from the blurb and examples in
the docs? Or any other possible kwarg and how they're used, including
special operators like "**" ?
If there's a tutorial somewhere on kwargs in general, what specific
types of kwargs there are, what special operators can be specifed for
them and how the kwargs are used, it would be very helpful to have that
tutorial referenced in a footnote-link next to kwargs whenever kwargs is
part of a function specification.
Or, if no such tutorial exists, the footnote-link could point to any
more detailed information that might explain what this creature "kwargs"
might be.
I have an item on my todo list to google "python kwargs", but it keeps
getting pushed deeper and deeper down my list because I have so little
hope that it will turn up anything useful.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Survey: improving the Python std lib docs
Cem Karan wrote, on Wednesday, May 17, 2017 2:48 AM > > On May 16, 2017, at 12:36 PM, rzed wrote: > > > On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote: > >> One of the more controversial aspects of the Python > ecosystem is the > >> Python docs. Some people love them, and some people hate them and > >> describe them as horrible. > >> > > [...] > > > > One thing I would love to see in any function or class docs is a few > > example invocations, preferably non-trivial. If I need to > see more, I can read the entire doc, but most times I just > want a refresher on how the function is called. Does it use > keywords? Are there required nameless parameters? In what > order? A line or two would immediately clarify that most of the time. > > > > Apart from that, links to docs for uncommon functions (or > to the docs > > of the module, if there are many) would be at least somewhat useful. > > I'd like to see complete signatures in the docstrings, so > when I use help() on something that has *args or **kwargs I > can see what the arguments actually are. > > Thanks, > Cem Karan I'd also like to see all of the above, especially what the possible *args or **kwargs are. Sure hope someone who might do these things is reading this. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
> Chris Angelico wrote, on Tuesday, May 16, 2017 9:50 PM > > For the person who's using it, or for all the malware authors > > who are gleefully using your computer as their own > > playground? It certainly is a fine operating system for the latter. > > > > ChrisA > > Nobody's used my XP for a malware playground since about > 2006. I used to have about a dozen traps and traces that put > a stop to all that. Now I only have one, and it hasn't seen > hide nor hair of a single trace or sign of malware in the 6 > or so years that I've had only that one sentry. > > Not my problem if people can't use their computers and browse > the web sensibly. And I repeat, it's not something I should > be continually beat around the head about. > > So please stop beating me up about it, you fools. > > Deborah Can you imagine how much money and grief could have been saved with a massive computer and internet use education blitz back in about 2005, instead of the coddling and "saving from the malware monsters" that we got instead? I figured out how to do it, surely others could. (I was way too sick then to do any more than protect myself.) People are barely little safer from malware today than they were in 2005. The evidence from that is the proliferation of identity theft, fraudulent tax returns for refunds and the pervasive presence, power and purloined wealth of the malware kings. And they don't just prey on hapless XP users, follow the research yourself. Windows 7+ is outstripping XP victims now, no doubt all the shaming to make XP users upgrade has merely decimated their numbers and made the bandwagon climbers-on vulnerable to all the Windows7+ tools the malware kings can now employ (don't you guys read any of this stuff?). Windows 7+ is no protection from malware, the malware kings are just stealthier and more technically expert now. Just because your machine isn't behaving like a malware-ridden XP did in the early 2000's doesn't mean that the malware kings aren't getting you. But the myth that modern Windows users are safe from malware is just that, a myth. I have plenty of Microsoftie friends who tell me privately that this is so. And if these new operating systems were designed from the get go to be so safe from malware, why the need for the constant stream of patches, and the thousands (or more) of zero-days they haven't devised patches for yet, or they even know are out there to be patched? Why are botnets still a flourishing enterprise, and now ransomware is on the rise? Hint, the malware kings aren't raking in all their wealth and power from XP machines alone. It's a strange, strange world when people surrender their responsibilities to the money makers who promise them safety and security with no sweat required. And they get to let the NSA and other government black actors spy on them for free in the bargain. It's a strange, strange world. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Wednesday, May 17, 2017 12:02 AM > > On Wed, May 17, 2017 at 4:59 PM, Deborah Swanson > wrote: > > So perhaps now you might be agreeing with me that investing > in Windows > > and Visual Studio now is a shortsighted move that will > likely result > > in long term grief for Python? Maybe reconsidering it? > > Not at all. I never said Windows wasn't important - just that > it isn't secure. Having Python able to run on Windows is a > HUGE benefit for the people who use Windows. Obviously it has > a cost, and a quite significant one, but it's not a bad > decision on the part of the Python core devs. > > But if Windows were to die a quiet death (or, as some have > predicted, progressively morph into being a skin atop Linux, > and then get spun off as an open source project while > Microsoft concentrates on Azure), it would in my opinion be a > great boon for the world. > > ChrisA Indeed. And it made me glad to read earlier in this thread that Python devs are leaving themselves a way out of this partnersip with Visual Studio, in the form of only agreeing to use the VS for currently supported Windows (or something like that). I suppose that's at least one reason why XP has become a pariah in the Python world, and I still predict grief coming from the Python-Visual Studio alliance. But so it goes. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Tuesday, May 16, 2017 11:36 PM > > On Wed, May 17, 2017 at 4:31 PM, Deborah Swanson > wrote: > > But the myth that modern Windows users are safe from > malware is just > > that, a myth. I have plenty of Microsoftie friends who tell me > > privately that this is so. > > Which is why people who care about security use BSD, not Windows. > > ChrisA Oh, I see. Now you're morphing your attack on Windows XP to all flavors of Windows? Not that I would entirely disagree. As I've said at least a dozen times now, XP is merely an expediency for me until I can get resituated in Linux, and I wouldn't have any Windows released after XP SP2. So perhaps now you might be agreeing with me that investing in Windows and Visual Studio now is a shortsighted move that will likely result in long term grief for Python? Maybe reconsidering it? Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Tuesday, May 16, 2017 9:50 PM > > On Wed, May 17, 2017 at 2:14 PM, Deborah Swanson > wrote: > > So please, all of you, stop beating me up about continuing > to use XP. > > It really is a fine operating system, but everyone else > wants to get > > on with their lives and stop supporting it. Not my fault, nor is it > > something I should be continually beat around the head about. > > > > For the person who's using it, or for all the malware authors > who are gleefully using your computer as their own > playground? It certainly is a fine operating system for the latter. > > ChrisA Nobody's used my XP for a malware playground since about 2006. I used to have about a dozen traps and traces that put a stop to all that. Now I only have one, and it hasn't seen hide nor hair of a single trace or sign of malware in the 6 or so years that I've had only that one sentry. Not my problem if people can't use their computers and browse the web sensibly. And I repeat, it's not something I should be continually beat around the head about. So please stop beating me up about it, you fools. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Nathan Ernst wrote, on Tuesday, May 16, 2017 8:33 PM > Deborah, long term, you have to realize that if you insist on > sticking to WinXP, the rest of the world will, eventually, > leave you behind.Software vendors want to support the fewest > platforms/configurations as possible. XP is not supported by > MS, so it makes no economic sense to an ISV to support XP. Just to clarify, again (and again a dozen times), I will have a Linux machine again as soon as it's possible within my constraints. So please, all of you, stop beating me up about continuing to use XP. It really is a fine operating system, but everyone else wants to get on with their lives and stop supporting it. Not my fault, nor is it something I should be continually beat around the head about. I'm doing the best that I can. I'd like to see you know-it-alls do it as well as I have, as crippled up with something closely related to hydrocephalus for the last 15 years that the doctors gave up trying to diagnose in 2005 and dirt poor as I am. But I diagnosed it and I'm slowly getting well from it, and somehow I've managed to live in a house with a nice garage and my trusty '76 Toyota pickup - and no it wasn't my fairy godmother who gave it all to me. Some of us were born thrifty and resourceful. And I've been reading closely all the posts since I dropped out of this thread. I saw no point in replying "that's nice, but I didn't know that" to each one, but I'll definitely refer to this thread when I get this far. So thank you all. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Monday, May 15, 2017 4:55 PM > > Deborah Swanson wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? > > The setup and installation code *is* written in Python. It's > just that some of the source of the particular package you're > trying to install is written in C, so installing it *from > source* necessarily requires a C compiler. > > Most people's Windows machines aren't set up for compiling C > code, and for that reason, prebuilt versions of such packages > are usually supplied for Windows. > > So you have two reasonable options: > > 1) Find a prebuilt wheel that's compatible with your system. > > 2) Find another package written in pure Python that does what > you want. > > It's also possible that you don't need the parts of > recordclass that are written in C. If that's the case you > might be able to install the pure Python parts manually. > That's usually just a matter of dropping the .py files in > appropriate places. That might end up being the best choice for me, although I'm not entirely sure what the appropriate places to drop the .py files are. Probably the Scripts directory is one of them, but I don't know which files go there and which files go other places, and I definitely don't know what those other places are. However, I think MRAB's success in pip installing recordclass after upgrading pip might make workarounds unnecessary for me. I also haven't upgraded pip since I last installed Python, and I did see a nag notice that I should upgrade it. So that seems like the next step. > > Relatedly, why is Python lacking in the basic build tools for users to > > easily build and install packages and full releases from source? > > Something for Python (loosely) akin to the earliest versions of Visual > > Studio would do the job, > > Having the Python ecosystem stuck on some ancient version of > Visual Studio would be a bad situation for many reasons. Oh, and I was never thinking that should be done, that's why I said "loosely akin to". Just something along those lines, updated for Python and current realities, not the genuine original in the flesh! My point then was to develop purely Python tools to do the job we're leaning on Visual Studio to do, but I've learned in the last few messages why that might be more complicated than I originally thought it would be. > One > of the main uses of C extensions is to interface with > external libraries, which will most likely have been compiled > with a recent toolset and rely on recent versions of > Microsoft's runtime libraries. Another point I was unaware of, so thanks. > There's also the fact that Microsoft doesn't make the free > versions of Visual Studio available forever and forbids > anyone else distributing them, so sufficiently old versions > are simply not available to most people. Another reason why it's sad that Python hasn't been making its own build tools, or incorporating and developing open software tools all along. This is a tail that could easily end up wagging the dog, and soon. But likely there are stll many things I don't know or haven't fully understood from what I've learned today. > The alternative would be to use some other free compiler such > as MinGW as the standard compiler for Python and its > extensions. But this has been decided against on the grounds > that it is better to use the standard Windows tools to > compile code for Windows, for the same compatibility reasons > as above, and that means Visual Studio. Well, apparently that was the choice. I for one think it's sad, and that it will lead to trouble for Python somewhere down the road. Probably the trouble will be in its capacity to be available on all platforms, and I think it's sad to have such binding ties with newer Windows. Time will tell, but I think Windows is a slowly sinking ship, not unlike the eventual fate of the behemoth IBM. It's the way of all things, and Microsoft is no more immune to natural processes than anything else is. > > Ah, and you've got me there. I have no clue what an ABI tag is or why > > it's significant, > > ABI = Application Binary Interface. Essentially it's the > interface between the Python interpreter and code that's been > compiled from C, and it can change from one version of Python > to another. Thanks! Another mysterious acronym demystified! > The error message from pip could
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 2:58 PM > > On Tue, May 16, 2017 at 7:01 AM, Deborah Swanson > wrote: > > But I'm a little more mystified that official Python builds are > > leaning on Visual C++ (and that's what the crutch comment was > > primarily aimed at). Perhaps they're just as resource needy as the > > extension developers are and new requirements have come up as Python 3 > > progresses that they don't already have Python build and installation > > tools written and tested for. I'd be willing to step into that void > > when my Python skills are equal to the task (and my health permitting, > > of course). But that would be years from now, and maybe someone else > > will step up before then. I'm really thinking that build has > > languished far behind the rest of the language's development for way > > too long. > > > > > > Maybe I have more pride in the Python language than is right and > > proper, but I do think it would be worth the relatively small > > investment to make and start growing Python's own build and > > installation tools asap. Python will be the reigning Queen of coding > > languages someday. Certainly seems like she should have all her own > > working parts and be beholden to no one. ;) > > You seem to be of the opinion that some day, binary > executables will be compiled using pure Python code. Well, my naive opinion is that they should be. But it was just one message back that I learned some Python built-in modules are at least partially written in C. I didn't know that, nor did I know or suspect that installation files for official Python releases likely contained C compilers. This raises a lot of questions for me, though it probably would be better for me to read and think about them on my own before coming back here with anything. > Maybe > that's true; maybe it's not. The point is, though, that high > performance binaries can't be created without a LOT of > expertise relating to the OS, the standard library, the CPU > architecture, etc, etc, etc. That expertise has been > coalesced into existing C compilers (I mentioned gcc, clang, > and msvc earlier; others also exist but those are the most > popular), and throwing that out means having a subpar Python. I'll accept that, though I still don't quite understand the recent dependence on Visual C++, after Python has been building its releases with the tools you and others mention from the beginning until shortly after the first 3 build was released, and the requirement has been so much deeper since 3.4.3, that Python (apparently) can no longer use the Visual C++ compiler built into XP. These are just things I wonder about since these new requirements put a real crimp in what I'm currently able to do, and I wonder how they will change Linux too. Again, lots of stuff for me to pursue on my own here. > Perhaps a future version of gcc will be implemented in > Python. Would you then say that Python is beholden to no one? > You would still need to have a C compiler installed in order > to compile extension modules. It's too big to include with > every single Python installation. So you'd have the same > situation even then. > > ChrisA No, with what I've learned today, I certainly would agree that Python has its beholdens, and likely always will. The bright side is that Python at least doesn't appear to be unduly constrained in how it uses the C/C++ code it does. I just hope that it continues to be kept to a minimum, but I guess I'm just a stinking purist about some things. Just another pretty fantasy smashed. So it goes. It's definitely better to have broken fantasies to feel bad about having, and to know the truth. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Nathan Ernst wrote, on Monday, May 15, 2017 2:14 PM Deborah, I get the feeling you don't understand the architecture/implementation of Python. The (C)Python interpreter is written in C. A number of the built-in modules are least partially written in C. As such, C is a natural integration point for extensions. Many, many third-party extensions are written completely or partially in C or C++. If you're going to install Python or these modules from source, you need a C or C++ compiler. On Windows, this tends to be MSVC. On Linux, GCC or clang. On OS X, clang. > You would be right, it has never occurred to me that built-in modules to the > language would be partially written in C. I'll plan to have a C compiler > asap, but it probably won't be until I'm up and running on Linux again. You may consider C & C++ to be lesser languages, but Python's built upon those "lesser" languages. Personally, I love both C++ & Python. You need to know when to use the write tool for the job (hammer vs screwdriver). > That may well be, and probably I should tone down my snark about C/C++. This > is why it's good to talk to people about these thoughts that might be > running amok and undetected inside your own head. That happens all too > easily when you spend years reading and studying alone, so thanks, and I'll > be looking more closely at C/C++ and it's role today. Comparing Python to MSDOS is comparing apples to oranges. MSDOS is not a language. It is an operating system (albeit a bare-bones, single-user one). Regards, Nathan On Mon, May 15, 2017 at 4:01 PM, Deborah Swanson wrote: Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? Surely Python has the required > > functionality, and it seems more than a little demeaning for Python to > > be using Visual C++ as a crutch. > > Are you suggesting that a C compiler should be written in > Python? Because you're dealing with an extension library. > It's not written in pure Python. That's why it needs a C > compiler. While it is certainly possible to write a C > compiler in Python, it is unlikely to outperform the existing > popular compilers (gcc, clang, msvc, etc), which have had > many years of expertise poured into them. I don't know much about extensions yet, but I think I can see what you're saying. It probably is a shortcut for volunteer developers to use existing C/C++ code where they can, rather than writing all of it from scratch in Python. But I'm a little more mystified that official Python builds are leaning on Visual C++ (and that's what the crutch comment was primarily aimed at). Perhaps they're just as resource needy as the extension developers are and new requirements have come up as Python 3 progresses that they don't already have Python build and installation tools written and tested for. I'd be willing to step into that void when my Python skills are equal to the task (and my health permitting, of course). But that would be years from now, and maybe someone else will step up before then. I'm really thinking that build has languished far behind the rest of the language's development for way too long. > None of this applies if you are actually depending on a pure > Python module, which *can* be installed without a C compiler. > Visual C++ is not a crutch but a critical part of the build process. > > ChrisA I'll still think of it as a crutch for official Python builds, but I can see your point for extension developers. Maybe I have more pride in the Python language than is right and proper, but I do think it would be worth the relatively small investment to make and start growing Python's own build and installation tools asap. Python will be the reigning Queen of coding languages someday. Certainly seems like she should have all her own working parts and be beholden to no one. ;) Microsoft saw the need for build and installation teams very early on, and now everyone depends on what they made. And yes, Windows and all Microsoft software from thence forward was primarily made with C/C++, because MSDOS was appallingly incapable of meeting the challenge and that's all they had before Windows. Python has a lot more than MSDOS ever dreamed of, and that's what seems demeaning to me that Python is piggybacking on a lesser language, because their need to do so is so infinitesimally less than Microsoft's need was to move on from MSDOS. And I think the day is coming that Microso
RE: How to install Python package from source on Windows
MRAB wrote, on Monday, May 15, 2017 12:44 PM > > On 2017-05-15 13:52, eryk sun wrote: > > On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson > > wrote: > >> > >> Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There > >> weren't any win32 builds on > https://pypi.python.org/pypi/recordclass. > > > > It's in the > middle of the file list: > > > > recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel cp34 > > 2017-04-17 17KB > > > > Maybe you're looking at a cached page in your browser? But that > > doesn't explain why pip doesn't see it. > > > >> Maybe I can find an earlier 3 build that won't demand Visual C++. > > > > The wheel doesn't need a compiler. It has an ABI tag because it > > already includes the compiled extension module. > > > I used pip to install into Python 3.4 (32-bit) from PyPI. It fetched > "recordclass-0.4.3.tar.gz" and compiled it instead of fetching > "recordclass-0.4.3-cp34-cp34m-win32.whl". > > Why? Excellent question, though I have no clue what the answer is. > Come to think of it, what's that "cp34m" in the name? I don't have that > in the regex module's wheels, I have "none" instead. Another excellent question. "cp" in "cp34m" might stand for C++, but if so, what's the rest of it mean? Or maybe "CPython 3.4" plus "m" (whatever "m" stands for)? What's "the regex module's wheels"? I certainly don't know, though I know vague outines of what "regex" and "wheel" are. > Rename "recordclass-0.4.3-cp34-cp34m-win32.whl" to > "recordclass-0.4.3-cp34-name-win32.whl". > > With the new name, it installs and seems to work! Most excellent and I will try it. As a mutable alternative to namedtuples, recordclass certainly seems worth the detour to look at and try, if I can get it to install! All of the hairy points I've run into with namedtuples revolve around their immutability. Getattr works and solves some of them, but it's helpless and breaks with the "object has no attribute xxx" in others. So a mutable version of namedtuple functionality would be extremely useful indeed. I'll also take a look at the contents of "recordclass-0.4.3.tar.gz" to see what I can see. Maybe not much though. I'm real ignorant of how extensions are made, but I might see something worth seeing. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? Surely Python has the required > > functionality, and it seems more than a little demeaning for Python to > > be using Visual C++ as a crutch. > > Are you suggesting that a C compiler should be written in > Python? Because you're dealing with an extension library. > It's not written in pure Python. That's why it needs a C > compiler. While it is certainly possible to write a C > compiler in Python, it is unlikely to outperform the existing > popular compilers (gcc, clang, msvc, etc), which have had > many years of expertise poured into them. I don't know much about extensions yet, but I think I can see what you're saying. It probably is a shortcut for volunteer developers to use existing C/C++ code where they can, rather than writing all of it from scratch in Python. But I'm a little more mystified that official Python builds are leaning on Visual C++ (and that's what the crutch comment was primarily aimed at). Perhaps they're just as resource needy as the extension developers are and new requirements have come up as Python 3 progresses that they don't already have Python build and installation tools written and tested for. I'd be willing to step into that void when my Python skills are equal to the task (and my health permitting, of course). But that would be years from now, and maybe someone else will step up before then. I'm really thinking that build has languished far behind the rest of the language's development for way too long. > None of this applies if you are actually depending on a pure > Python module, which *can* be installed without a C compiler. > Visual C++ is not a crutch but a critical part of the build process. > > ChrisA I'll still think of it as a crutch for official Python builds, but I can see your point for extension developers. Maybe I have more pride in the Python language than is right and proper, but I do think it would be worth the relatively small investment to make and start growing Python's own build and installation tools asap. Python will be the reigning Queen of coding languages someday. Certainly seems like she should have all her own working parts and be beholden to no one. ;) Microsoft saw the need for build and installation teams very early on, and now everyone depends on what they made. And yes, Windows and all Microsoft software from thence forward was primarily made with C/C++, because MSDOS was appallingly incapable of meeting the challenge and that's all they had before Windows. Python has a lot more than MSDOS ever dreamed of, and that's what seems demeaning to me that Python is piggybacking on a lesser language, because their need to do so is so infinitesimally less than Microsoft's need was to move on from MSDOS. And I think the day is coming that Microsoft will be too much of a dinosaur (like IBM has become) to continue meeting the needs of evolving languages. Better to get going on our own tools, the sooner the better, in my opinion. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote, on Monday, May 15, 2017 5:52 AM
>
> On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson
> wrote:
> >
> > Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There
> > weren't any win32 builds on
> https://pypi.python.org/pypi/recordclass.
>
> It's in the middle
> of the file list:
>
>recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel
> cp34 2017-04-17 17KB
Actually, I see now there are several win32.whl files on that page. I'm
not familiar with PyPi's link formatting and I didn't realize that both
the wheel and md5 files were available from each of those links, and I
only clicked on the md5s. (Truth be told I didn't even see the .whls. It
was late, and though I could read and write, I was a little bleary
around the edges.)
> Maybe you're looking at a cached page in your browser? But
> that doesn't explain why pip doesn't see it.
Actually, when I tried "pip install
recordclass-0.4.3-cp34-cp34m-win32.whl" it failed almost immediately
with:
"recordclass-0.4.3-cp34-cp34m-win32.whl is not a supported wheel on this
platform."
The one time I tried "pip install recordclass", it found
0.4.3-cp34-cp34m-win32 alright. It got as far as copying, building and
testing it, but failed in test:
Installing collected packages: recordclass
Running setup.py install for recordclass
Complete output from command C:\Programs\Coding\Anaconda3\python.exe
-c "imp
ort setuptools,
tokenize;__file__='E:\\temp\\pip-build-zhximvpd\\recordclass\\se
tup.py';exec(compile(getattr(tokenize, 'open',
open)(__file__).read().replace('\ r\n', '\n'), __file__, 'exec'))"
install --record E:\temp\pip-r7ky4fv1-record\in stall-record.txt
--single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib.win32-3.4
creating build\lib.win32-3.4\recordclass
copying lib\recordclass\record.py -> build\lib.win32-3.4\recordclass
copying lib\recordclass\__init__.py ->
build\lib.win32-3.4\recordclass
creating build\lib.win32-3.4\recordclass\test
copying lib\recordclass\test\test_memoryslots.py ->
build\lib.win32-3.4\reco rdclass\test
copying lib\recordclass\test\test_record.py ->
build\lib.win32-3.4\recordcla ss\test
copying lib\recordclass\test\__init__.py ->
build\lib.win32-3.4\recordclass\ test
running build_ext
building 'recordclass.memoryslots' extension
error: Microsoft Visual C++ 10.0 is required (Unable to find
vcvarsall.bat).
So it choked when it needed Visual C++ to test the installation, at
least that's what I'm assuming it was testing.
It continues to amaze me that Anaconda and Python.org, probably the two
biggest distributors of official Python builds, are now relying on
Visual C++. Why can't Python developers write the entire setup and
installation code in Python? Surely Python has the required
functionality, and it seems more than a little demeaning for Python to
be using Visual C++ as a crutch.
Relatedly, why is Python lacking in the basic build tools for users to
easily build and install packages and full releases from source?
Something for Python (loosely) akin to the earliest versions of Visual
Studio would do the job, and it wouldn't have to be real tricked out.
I've seen this lack show up in several threads on this list, including
my original question in this thread. I was fishing for hints about the
build tools in Python as a way to build recordclass from source, but
apparently there aren't any. Not that advanced users know about anyway.
Is the Python dev team so lacking in resources that they can't cover
this fundamental base? Microsoft had build teams in dev at least as
early as the first release of Windows NT, and probably much earlier. I'd
always assumed that major language developers would establish build and
installation teams very early on. Alhough, Microsoft's setup teams still
really sucked bananas as late as when the the first XP was released in
2001 (don't know anything about them since), but the build teams were
rock stars that everyone looked up to from the get go. Apparently Python
hasn't mirrored that sequence of development steps.
> > Maybe I can find an earlier 3 build that won't demand Visual C++.
>
> The wheel doesn't need a compiler. It has an ABI tag because
> it already includes the compiled extension module.
Ah, and you've got me there. I have no clue what an ABI tag is or why
it's significant, and I don't know a fraction enough about wheels to
know whether they'd use a compiler or not. Grist for the mill, so
thanks.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 1:02 AM > > On Mon, May 15, 2017 at 4:48 PM, Deborah Swanson > wrote: > > Chris Angelico wrote on Sunday, May 14, 2017 11:30 PM > >> > >> On Mon, May 15, 2017 at 4:28 PM, Deborah Swanson > >> wrote: > >> > > >> > Again, maybe I should go back to Python 2 for this. > >> > >> Won't help. The same problems will exist. > >> > >> ChrisA > >> > > > > Good to know. Maybe I just won't be able to try > recordclass until I > > get Linux set up one way or another. Right now it's more > important to > > me to spend the few hours a day I have making progress in Python. > > > > (Now, if I can figure out how to make gettattr work in this one > > namedtuple problem, I won't need anything like recordclass. I've > > converted three more Excel spreadsheets to Python, but it's tricky > > working with namedtuples when you want to group rows or > take n colomns > > at a time. I've done it, but this one is really tough.) > > Hmm. If you're working heavily with tabular data, you may > want to consider numpy or pandas, both of which are designed > for major computational work and will happily manipulate rows > or columns of data. Both are well supported on Windows (and > everywhere). They do have their own learning curve though. > > ChrisA > -- Yes. I want to spend more time with numpy and learn pandas, but right now I do have to consider the learning curves involved. Maybe in 4-5 months I'll pull out of this wretched state I'm in now, and I'll spread my wings in dozens of directions then - for about a year, don't ask me how I know. (I haven't calculated out beyond 2017 yet.) But there's another issue too. Contrary to popular belief, just because spreadsheets are what you build on a rectangular grid of cells, not many advanced spreadsheet applications are straight-up tabular. Most beginners start out tabular (though I didn't, a couple decades ago), and it seems that most never get out of the tabular framework. I've been finding that namedtuples covers a good 90-95% of my "not exactly tabular" (and "not at all tabular") spreadsheet applications, and I'm quite curious to keep extending my knowledge about what you can do with namedtuples. And it probably would be surprising to some how much that is. It's mainly a few awkward corner cases, like grouping rows and taking columns n at a time that can really be tricky. (But I've done both now.) Eventually I plan to know several tools to convert spreadsheets to Python with, including numpy and pandas. But considering the "tabular" discipline both of those have, I doubt I'd be saving myself any grief by switching to them. Learning curves are a bitch in their own right, and I can think of worse ways to spend a few broken months than getting to know one way really well. It's my fallback position when things get bad, to just stick with what I don't have to learn too much about and find out what I can do with it. You'd be surprised! Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote on Sunday, May 14, 2017 11:30 PM > > On Mon, May 15, 2017 at 4:28 PM, Deborah Swanson > wrote: > > > > Again, maybe I should go back to Python 2 for this. > > Won't help. The same problems will exist. > > ChrisA > Good to know. Maybe I just won't be able to try recordclass until I get Linux set up one way or another. Right now it's more important to me to spend the few hours a day I have making progress in Python. (Now, if I can figure out how to make gettattr work in this one namedtuple problem, I won't need anything like recordclass. I've converted three more Excel spreadsheets to Python, but it's tricky working with namedtuples when you want to group rows or take n colomns at a time. I've done it, but this one is really tough.) -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote on Sunday, May 14, 2017 9:27 PM > > On Mon, May 15, 2017 at 4:19 AM, Deborah Swanson > wrote: > > Unfortunately I don't have Visual Studio 2015+ installed > and I can't > > install it on Windows XP SP2 (plus I really don't want to). > Probably I > > should have mentioned that, but I didn't know I'd need to > build C/C++. > > 3.5+ doesn't work in XP, so the highest version you can run > is 3.4. For 32-bit, install recordclass-0.4.3-cp34-cp34m-win32.whl. > Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There weren't any win32 builds on https://pypi.python.org/pypi/recordclass. Maybe I can find an earlier 3 build that won't demand Visual C++. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote, on Sunday, May 14, 2017 9:27 PM > > On Mon, May 15, 2017 at 4:19 AM, Deborah Swanson > wrote: > > Unfortunately I don't have Visual Studio 2015+ installed > and I can't > > install it on Windows XP SP2 (plus I really don't want to). > Probably I > > should have mentioned that, but I didn't know I'd need to > build C/C++. > > 3.5+ doesn't work in XP, so the highest version you can run > is 3.4. For 32-bit, install recordclass-0.4.3-cp34-cp34m-win32.whl. > I have 3.4.3 installed. That was the last build it was possible to get out of Anaconda for XP, and there's lots of goodies I have to do without or work around. But, "pip install recordclass-0.4.3-cp34-cp34m-win32.whl" fails with: "recordclass-0.4.3-cp34-cp34m-win32.whl is not a supported wheel on this platform." Probably because it wants to use C++, or Visual something (higher than version 4). Unless you know how I can install recordclass without using pip, and recordclass-0.4.3-cp34-cp34m-win32.whl won't fail if it can't find Visual C++. Again, maybe I should go back to Python 2 for this. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Sunday, May 14, 2017 9:56 PM
>
> On Mon, May 15, 2017 at 2:26 PM, eryk sun wrote:
> > On Mon, May 15, 2017 at 4:19 AM, Deborah Swanson
> > wrote:
> >> Unfortunately I don't have Visual Studio 2015+ installed
> and I can't
> >> install it on Windows XP SP2 (plus I really don't want
> to). Probably
> >> I should have mentioned that, but I didn't know I'd need to build
> >> C/C++.
> >
> > 3.5+ doesn't work in XP, so the highest version you can run is 3.4.
> > For 32-bit, install recordclass-0.4.3-cp34-cp34m-win32.whl.
>
> The best way to install this sort of thing is using pip. You
> should have it with your Python 3.4, and it'll do all the
> work of figuring out which one to download.
>
> ChrisA
> --
That was easy to try, "pip install recordclass", but it failed:
C:\Programs\Coding\Anaconda3\Scripts>pip install recordclass
You are using pip version 7.0.3, however version 9.0.1 is available.
You should consider upgrading via the 'python -m pip install --upgrade
pip' comm
and.
Collecting recordclass
Downloading recordclass-0.4.3.tar.gz
Installing collected packages: recordclass
Running setup.py install for recordclass
Complete output from command C:\Programs\Coding\Anaconda3\python.exe
-c "imp
ort setuptools,
tokenize;__file__='E:\\temp\\pip-build-zhximvpd\\recordclass\\se
tup.py';exec(compile(getattr(tokenize, 'open',
open)(__file__).read().replace('\
r\n', '\n'), __file__, 'exec'))" install --record
E:\temp\pip-r7ky4fv1-record\in
stall-record.txt --single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib.win32-3.4
creating build\lib.win32-3.4\recordclass
copying lib\recordclass\record.py -> build\lib.win32-3.4\recordclass
copying lib\recordclass\__init__.py ->
build\lib.win32-3.4\recordclass
creating build\lib.win32-3.4\recordclass\test
copying lib\recordclass\test\test_memoryslots.py ->
build\lib.win32-3.4\reco
rdclass\test
copying lib\recordclass\test\test_record.py ->
build\lib.win32-3.4\recordcla
ss\test
copying lib\recordclass\test\__init__.py ->
build\lib.win32-3.4\recordclass\
test
running build_ext
building 'recordclass.memoryslots' extension
error: Microsoft Visual C++ 10.0 is required (Unable to find
vcvarsall.bat).
Command "C:\Programs\Coding\Anaconda3\python.exe -c "import setuptools,
tokenize
;__file__='E:\\temp\\pip-build-zhximvpd\\recordclass\\setup.py';exec(com
pile(get
attr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'),
__file__, '
exec'))" install --record E:\temp\pip-r7ky4fv1-record\install-record.txt
--singl
e-version-externally-managed --compile" failed with error code 1 in
E:\temp\pip-
build-zhximvpd\recordclass
Looks like lack of Visual C++ tripped me up again.
Strange how Python code can't install with purely Python code. I don't
plan to have Visual anything on Linux either.
It might be possible to do something with
lib\recordclass\test\test_record.py ->
build\lib.win32-3.4\recordclass\test and
lib\recordclass\record.py -> build\lib.win32-3.4\recordclass,
but I wouldn't know what.
Maybe I should go back to Python 2.7.8 for this.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote, on Sunday, May 14, 2017 7:15 PM
>
> On Sun, May 14, 2017 at 8:46 PM, Deborah Swanson
> wrote:
> > I want to install the recordclass package:
> > https://pypi.python.org/pypi/recordclass
> >
> > But they've only released wheel files for two platforms, macosx and
> > win_amd64, neither of which will install on my system. I
> need win_x86
> > or intel_x86, which they don't provide.
>
> The tag for 32-bit Windows is "win32". The PyPI page has
> win32 wheels for 2.7-3.5.
I'll look at the PyPi page again, it's true I skipped over the Python2
builds, but if that turns out tobe my best option, I can rewrite my
project for Python2.
> If you're using 3.6, you'll have to build from source. The
> package has a single C extension without external
> dependencies, so it should be a straight-forward build if you
> have Visual Studio 2015+ installed with the C/C++ compiler
> for x86.
Unfortunately I don't have Visual Studio 2015+ installed and I can't
install it on Windows XP SP2 (plus I really don't want to). Probably I
should have mentioned that, but I didn't know I'd need to build C/C++.
> Ideally it should work straight from pip. But I
> tried and it failed in 3.6.1 due to the new
> PySlice_GetIndicesEx macro. Apparently MSVC doesn't like
> preprocessor code like this in
> memoryslots.c:
>
> #if PY_MAJOR_VERSION >= 3
> if (PySlice_GetIndicesEx(item, Py_SIZE(self),
> #else
> if (PySlice_GetIndicesEx((PySliceObject*)item,
> Py_SIZE(self),
> #endif
> &start, &stop, &step,
> &slicelength) < 0) {
>
> It fails with a C1057 error (unexpected end of file in macro
> expansion). The build will succeed if you copy the common
> line with `&start` to each case and comment out the original
> line, such that the macro invocation isn't split across an
> #if / #endif. This is an ugly consequence of making
> PySlice_GetIndicesEx a macro. I wonder if it could be written
> differently to avoid this problem.
There isn't any solution or workaround for me if building C/C++ is
required.
--
https://mail.python.org/mailman/listinfo/python-list
How to install Python package from source on Windows
I want to install the recordclass package: https://pypi.python.org/pypi/recordclass But they've only released wheel files for two platforms, macosx and win_amd64, neither of which will install on my system. I need win_x86 or intel_x86, which they don't provide. The only alternative to pip install that I know of is to install from source, and the source I need is at: https://bitbucket.org/intellimath/recordclass/src I've never done this, so any help would be appreciated. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Bigotry (you win, I give up)
And the moral to the story is: Don't worry. Be happy. And reach fot the stars (while still being mindful of those around you). -- https://mail.python.org/mailman/listinfo/python-list
RE: The belief that learning is more difficult for older people (was: Bigotry (you win, I give up))
Poor souls. It isn't pretty when the mind lets go. Maybe it sounds cold, but these people did make the choice every day of most of their lives to not bother themselves about the why of things, to not pay attention to this, to let someone else worry about that, etc. The sad thing is that this ad is likely for prescription drugs, which may restore rudimentary mental function, but they won't restore your mind. Especially if you never cultivated one to begin with. At 65 years old, I'm surrounded by these people, many of whom I've known all my life, and I know how they've lived. Rustom Mody wrote, on Thursday, April 20, 2017 5:48 AM > > On Thursday, April 20, 2017 at 7:51:55 AM UTC+5:30, Ben Finney wrote: > > "Deborah Swanson" writes: > > > > > But this bit caught my eye because I hold the opposite > opinion about > > > old people's ability to learn. > > > > > > It is a choice. > > > > The topic is complex, and both "It is entirely determined > by your own > > choices" and "It is in no way determined by your own choices" are > > false. > > > > Received this today > > > > What is A.A.A.D.D. ? It is > Age Activated Attention Deficit Disorder. > > This is how it manifests: > > I decide to water my garden. > As I turn on the hose in the driveway, > I look over at my car and decide it needs washing. > > As I start toward the garage, > I notice mail on the porch table that > I brought up from the mail box earlier. > > I decide to go through the mail before I wash the car. > > I lay my car keys on the table, > put the junk mail in the garbage can under the table, > and notice that the can is full. > > So, I decide to put the bills back > on the table and take out the garbage first. > But then I think, > since I'm going to be near the mailbox > when I take out the garbage anyway, > I may as well pay the bills first. > > I take my cheque book off the table, > and see that there is only one cheque left. > > My extra cheques are in my desk in the study, > so I go inside the house to my desk where > I find the can of Coke I'd been drinking. > > I'm going to look for my cheques , > but first I need to push the Coke aside > so that I don't accidentally knock it over. > > The Coke is getting warm, > and I decide to put it in the refrigerator to keep it cold. > > As I head toward the kitchen with the Coke, > a vase of flowers on the counter > catches my eye--they need water. > > I put the Coke on the counter and > discover my reading glasses that > I've been searching for all morning. > > I decide I better put them back on my desk, > but first I'm going to water the flowers. > > I set the glasses back down on the counter, > fill a container with water and suddenly spot the TV remote. > Someone left it on the kitchen table. > > I realize that tonight when we go to watch TV, > I'll be looking for the remote, > but I won't remember that it's on the kitchen table, > so I decide to put it back in the den where it belongs, > but first I'll water the flowers. > > I pour some water in the flowers, > but quite a bit of it spills on the floor. > > So, I set the remote back on the table, > get some towels and wipe up the spill. > > Then, I head down the hall trying to > remember what I was planning to do. > > At the end of the day: > > the car isn't washed > > the bills aren't paid > > there is a warm can of Coke sitting on the counter > > the flowers don't have enough water, > > there is still only 1 cheque in my cheque book, > > I can't find the remote, > > I can't find my glasses, > > and I don't remember what I did with the car keys. > > Then, when I try to figure out why nothing got done today, > I'm really baffled because I know I was busy all day, > and I'm really tired. > > I realize this is a serious problem, > and I'll try to get some help for it, > but first I'll check my e-mail > > Do me a favour. > Forward this message to everyone you know, > because I don't remember whom I've sent it to. > > Isn't you yet? You are young... And your day is coming! > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Bigotry (you win, I give up)
> Rupee via Python-list writes:
>
> > I don't think stupid black people or senile old people should be
> > allowable because those are not choosable *behaviors*. But is
> > unable-to-learn old people a choosable behavior? You said that's ok.
I've mostly been ignoring this thread and its predecessors, and I
probably won't read all the recent posts to it.
But this bit caught my eye because I hold the opposite opinion about old
people's ability to learn.
It is a choice. Your noggin doesn't just conk out at a certain age, or
stage in the aging process. There are plenty of examples of scholars and
authors (and many others) who've kept their wits sharp and their minds
fully functional. Some till the day they died, others didn't quite last
the whole way.
There's two paths to keeping the mind forever alive ("forever" meaning
at least till death, we don't know what comes after that). Both are
almost purely physical.
One is to use the mind all one's life, and the principle is identical to
"use it or lose it", more commonly heard in athletic circles. But the
mind is like muscle, the more you use it the stronger it gets. And vice
versa. And I'm living proof that if you use your mind hard all your life
(since I was about 3, in my case), you can let it coast for at least a
decade and it will still be there, and it can still learn. Of course
there's a lengthy stage of bringing it out of mothballs, but it can be
done.
The other path I'm living proof of is the food you eat. The brain
responds badly to chemicals that enter the body, and particularly ones
you ingest in food. And the brain is blood thirsty. It particularly
craves grassfed and pastured red meat, the rarer the better, and organ
meats. I eat all forms of it, but the prize goes to wild red meats -
antelope, venison & wild boar. I'll spare you all the reasons why and
the evidence, but they are very good reasons.
I've also had university math and science professors who swore by heavy
daily exercise regimes, but I haven't done it and neither have aged
scholars who still had their good minds very late in life, so rigorous
exercise is not a requirement. I have no idea whether it's sufficient to
sustain and grow the mind either, but no doubt it helps.
So, it is a choice of how you live your life, and how important it is to
you to have a mind worth keeping. I see no reason to accord those people
who didn't care all their lives any special status.
Oh, and I think it's also a choice whether you are stupid or not,
barring physical abnormalities of the brain. Regardless of age, gender
or race.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Saturday, April 15, 2017 12:44 AM
>
> Deborah Swanson wrote:
>
> > I know it's your "ugly" answer, but can I ask what the '**' in
> >
> > fix = {label: max(values, key=len)}
> > group[:] = [record._replace(**fix) for record in group]
> >
> > means?
>
> d = {"a": 1, "b": 2}
> f(**d)
>
> is equivalent to
>
> f(a=1, b=2)
Thisis perfect Peter, thank you very much. Now I can understand why your
"ugly" fix works, instead of just seeing in the degugger that
mysteriously it does somehow work.
> so ** is a means to call a function with keyword arguments when you
want to
> decide about the *names* at runtime. Example:
>
> >>> def f(a=1, b=2):
> ... print("a =", a)
> ... print("b =", b)
> ... print()
> ...
> >>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
> ... f(**d)
> ...
> a = 10
> b = 2
>
> a = 1
> b = 42
>
> a = 100
> b = 200
Looks like a very handy type of "kwarg" to know about. It would be nice
if the doc writers weren't so mysterious about what can be used for
"kwargs", or they explained somewhere what the possible "kwargs" can be.
Even in the one index entry for "kwargs", all they say about what it is,
is "A dict of keyword arguments values", and that only applies to the
Signature object. I've see "kwargs" in articles other than for
namedtuples, always mysteriously, with no details on what the
possibilities are and how to use them. (Makes me wonder where you
learned all this ... ;)
> Starting from a namedtuple `record`
>
> record._replace(Location="elswhere")
>
> creates a new namedtuple with the Location attribute changed to
"elsewhere",
> and the slice [:] on the left causes all items in the `groups` list to
be
> replaced with new namedtuples,
>
> group[:] = [record._replace(Location="elsewhere") for record in group]
>
> is basically the same as
>
> tmp = group.copy()
> group.clear()
> for record in tmp:
> group.append(record_replace(Location="elsewhere"))
>
> To support not just Location, but also Kind and Notes we need
> the double asterisk.
I saw this in the debugger, but again didn't really understand why it
was working. So this really clears it up, and I plan to look at it in
the debugger again to be sure I understand it all. Thanks very much.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Roel Schroeven wrote, on Thursday, April 13, 2017 5:26 PM
>
> Gregory Ewing schreef op 13/04/2017 9:34:
> > Deborah Swanson wrote:
> >> Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >>
> >>> Personally I would immediately discard the header row
> once and for
> >>> all, not again and again on every operation.
> >> Well, perhaps, but I need the header row to stay in place to write
> >> the list to a csv when I'm done
> >
> > That's no problem, just write the header row separately.
> >
> > Do this at the beginning:
> >
> >header = [Record._make(fieldnames)]
> >records = [Record._make(row) for row in rows]
> >
> > and then to write out the file:
> >
> >writer = csv.writer(outputfile)
> >writer.writerow(header)
> >writer.writerows(records)
>
> I don't even think there's any need to store the field names anywhere
> else than in fieldnames. So unless I'm missing something,
> just do this
> at the beginning:
>
> fieldnames = next(rows)
> Record = namedtuple("Record", fieldnames)
> records = [Record._make(row) for row in rows]
>
> and this at the end:
>
> writer = csv.writer(outputfile)
> writer.writerow(fieldnames) # or writer.writerow(Record._fields)
> writer.writerows(records)
>
>
> --
> The saddest aspect of life right now is that science gathers
> knowledge faster than society gathers wisdom.
>-- Isaac Asimov
>
> Roel Schroeven
This is essentially what Peter Otten most recently recommended. I know
you got there first, but it is better to only get the header row to name
the fields as you and Greg Ewing suggested, and then use just the
records in processing the field data, using the field names only for the
output.
Thanks,
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Gregory Ewing wrote, on Thursday, April 13, 2017 12:17 AM > > Deborah Swanson wrote: > > But I think you got it right in your last sentence below. defaultdict > > copied them because they were immutable, > > No, definitely not. A defaultdict will never take it upon > itself to copy an object you give it, either as a key or a value. > > The copying, if any, must have occurred somewhere else, in > code that you didn't show us. > > Can you show us the actual code you used to attempt to > update the namedtuples? > > -- > Greg I think you've heard my sob story of how the actual code was lost (PyCharm ate it). I've made some attempts to recover that code, but honestly, at this point Peter Otten has showed my enough examples of getattr() that work with namedtuples with variable names, that I'd rather just accept that probably some tranformation of the structure I did caused the copying of values only. I remember looking at it in the debugger, but that code was convoluted and I don't think it's worth teasing out exactly what went wrong. (or figuring out how I did it in the first place) Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
MRAB wrote, on Friday, April 14, 2017 2:19 PM
>
> In the line:
>
> values = {row[label] for row in group}
>
> 'group' is a list of records; row is a record (namedtuple).
>
> You can get the members of a namedtuple (also 'normal' tuple) by
numeric
> index, e.g. row[0], but the point of a namedtuple is that you can get
> them by name, as an attribute, e.g. row.Location.
>
> As the name of the attribute isn't fixed, but passed by name, use
> getattr(row, label) instead:
>
> values = {getattr(row, label) for row in group}
>
> As for the values:
>
> # Remove the missing value, if present.
> values.discard('')
>
> # There's only 1 value left, so fill in the empty places.
> if len(values) == 1:
> ...
Thanks for this, but honestly, I'm namedtupled-out at the moment and I
have several other projects I'd like to be working on. But I saved your
suggestion with ones that others have made, so I'll revisit yours again
when I come back for another look at namedtuples.
> The next point is that namedtuples, like normal tuples, are immutable.
> You can't change the value of an attribute.
No you can't, but you can use
somenamedtuple._replace(kwargs)
to replace the value. Works just as well.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
fix = {label: max(values, key=len)}
group[:] = [record._replace(**fix) for record in group]
Peter Otten wrote, on Friday, April 14, 2017 2:16 PM
> > def complete(group, label):
> > values = {row[label] for row in group}
> > # get "TypeError: tuple indices must be integers, not str"
>
> Yes, the function expects row to be dict-like. However when
> you change
>
> row[label]
>
> to
>
> getattr(row, label)
>
> this part of the code will work...
>
> > has_empty = not min(values, key=len)
> > if len(values) - has_empty != 1:
> > # no value or multiple values; manual intervention needed
> > return False
> > elif has_empty:
> > for row in group:
> > row[label] = max(values, key=len)
>
> but here you'll get an error. I made the experiment to change
> everything
> necessary to make it work with namedtuples, but you'll
> probably find the
> result a bit hard to follow:
>
> import csv
> from collections import namedtuple, defaultdict
>
> INFILE = "E:\\Coding projects\\Pycharm\\Moving\\Moving 2017
> in - test.csv" OUTFILE = "tmp.csv"
>
> def get_title(row):
> return row.title
>
> def complete(group, label):
> values = {getattr(row, label) for row in group}
> has_empty = not min(values, key=len)
> if len(values) - has_empty != 1:
> # no value or multiple values; manual intervention needed
> return False
> elif has_empty:
> # replace namedtuples in the group. Yes, it's ugly
> fix = {label: max(values, key=len)}
> group[:] = [record._replace(**fix) for record in group]
> return True
>
> with open(INFILE) as infile:
> rows = csv.reader(infile)
> fieldnames = next(rows)
> Record = namedtuple("Record", fieldnames)
> groups = defaultdict(list)
> for row in rows:
> record = Record._make(row)
> groups[get_title(record)].append(record)
>
> LABELS = ['Location', 'Kind', 'Notes']
>
> # add missing values
> for group in groups.values():
> for label in LABELS:
> complete(group, label)
>
> # dump data (as a demo that you do not need the list of all
> records) with open(OUTFILE, "w") as outfile:
> writer = csv.writer(outfile)
> writer.writerow(fieldnames)
> writer.writerows(
> record for group in groups.values() for record in group
> )
>
> One alternative is to keep the original and try to replace
> the namedtuple
> with the class suggested by Gregory Ewing. Then it should
> suffice to also
> change
>
> > elif has_empty:
> > for row in group:
> > row[label] = max(values, key=len)
>
> to
>
> > elif has_empty:
> > for row in group:
> setattr(row, label, max(values, key=len))
>
> PS: Personally I would probably take the opposite direction
> and use dicts
> throughout...
Ok, thank you. I haven't run it on a real input file yet, but this seems
to work with the test file.
Because the earlier incarnation defined 'values' as
values = {row[label] for row in group}
I'd incorrectly guessed what was going on in
has_empty = not min(values, key=len).
Now that
values = {getattr(row, label) for row in group}
works properly as you intended it to, I see you get the set of unique
values for that label in that group, which makes the rest of it make
sense.
I know it's your "ugly" answer, but can I ask what the '**' in
fix = {label: max(values, key=len)}
group[:] = [record._replace(**fix) for record in group]
means?
I haven't seen it before, and I imagine it's one of the possible
'kwargs' in 'somenamedtuple._replace(kwargs)', but I have no idea where
to look up the possible 'kwargs'. (probably short for keyword args)
Also, I don't see how you get a set for values with the notation you
used. Looks like if anything you've got a comprehension that should give
you a dict. (But I haven't worked a lot with sets either.)
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter,
Retracing my steps to rewrite the getattr(row, label) code, this is what
sent me down the rabbit hole in the first place. (I changed your 'rows'
to 'records' just to use the same name everywhere, but all else is the
same as you gave me.) I'd like you to look at it and see if you still
think complete(group, label) should work. Perhaps seeing why it fails
will clarify some of the difficulties I'm having.
I ran into problems with values and has_empty. values has a problem
because
row[label] gets a TypeError. has_empty has a problem because a list of
field values will be shorter with missing values than a full list, but a
namedtuple with missing values will be the same length as a full
namedtuple since missing values have '' placeholders. Two more
unexpected inconveniences.
A short test csv is at the end, for you to read in and attempt to
execute the following code, and I'm still working on reconstructing the
lost getattr(row, label) code.
import csv
from collections import namedtuple, defaultdict
def get_title(row):
return row.title
def complete(group, label):
values = {row[label] for row in group}
# get "TypeError: tuple indices must be integers, not str"
has_empty = not min(values, key=len)
if len(values) - has_empty != 1:
# no value or multiple values; manual intervention needed
return False
elif has_empty:
for row in group:
row[label] = max(values, key=len)
return True
infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in -
test.csv")
rows = csv.reader(infile)
fieldnames = next(rows)
Record = namedtuple("Record", fieldnames)
records = [Record._make(fieldnames)]
records.extend(Record._make(row) for row in rows)
# group rows by title
groups = defaultdict(list)
for row in records:
groups[get_title(row)].append(row)
LABELS = ['Location', 'Kind', 'Notes']
# add missing values
for group in groups.values():
for label in LABELS:
complete(group, label)
Moving 2017 in - test.csv:
(If this doesn't come through the mail system correctly, I've also
uploaded the file to
http://deborahswanson.net/python/Moving%202017%20in%20-%20test.csv.
Permissions should be set correctly, but let me know if you run into
problems downloading the file.)
CLDesc,url,title,Description,Location,ST,co,miles,Kind,Rent,Date,first,b
r,Notes,yesno,mark,arc
Jan 3 1 bedroom/1 bath mobile $700 1br - (Mount
Vernon),http://skagit.craigslist.org/apa/5943737902.html,1 bedroom/1
bath mobile $700 1br - (Mount Vernon) - (Mount Vernon),1 bedroom/1 bath
mobile $700 1br,Mount Vernon,WA,sk,,trailer,700,1/3/2017,1/3/2017,1,no
smoking,,,deleted by its author
Jan 6 1 bedroom/1 bath mobile $700 1br - (Mount
Vernon),http://skagit.craigslist.org/apa/5943737902.html,1 bedroom/1
bath mobile $700 1br - (Mount Vernon) - (Mount Vernon),1 bedroom/1 bath
mobile $700 1br,,WA,,,trailer,700,1/6/2017,1/3/2017,1,no smoking,,,
Jan 10 1 bedroom/1 bath mobile $700 1br - (Mount
Vernon),http://skagit.craigslist.org/apa/5943737902.html,1 bedroom/1
bath mobile $700 1br - (Mount Vernon) - (Mount Vernon),1 bedroom/1 bath
mobile $700 1br,,700,1/10/2017,1/3/2017,1
Jan 17 1 bedroom/1 bath mobile $700 1br - (Mount
Vernon),http://skagit.craigslist.org/apa/5943737902.html,1 bedroom/1
bath mobile $700 1br - (Mount Vernon) - (Mount Vernon),1 bedroom/1 bath
mobile $700 1br,Mount Vernon,WA,,,trailer,700,1/17/2017,1/3/2017,1,no
smoking,,,
Jan 19 1 bedroom/1 bath mobile $700 1br - (Mount
Vernon),http://skagit.craigslist.org/apa/5943737902.html,1 bedroom/1
bath mobile $700 1br - (Mount Vernon) - (Mount Vernon),1 bedroom/1 bath
mobile $700 1br,Mount Vernon,WA,,,trailer,700,1/19/2017,1/3/2017,1,no
smoking,,,
Jan 26 1240 8th Avenue $725 2br - 676ft2 -
(Longview),http://portland.craigslist.org/clk/apa/5976442500.html,1240
8th Avenue $725 2br - 676ft2 - (Longview),1240 8th Avenue $725 2br -
676ft2,,725,1/26/2017,1/16/2017,2
Jan 16 1240 8th Avenue $725 2br - 676ft2 -
(Longview),http://portland.craigslist.org/clk/apa/5961794305.html,1240
8th Avenue $725 2br - 676ft2 - (Longview) - (Longview),1240 8th Avenue
$725 2br -
676ft2,Longview,WA,,,house,725,1/16/2017,1/16/2017,2,"detached garage,
w/d hookups",,,
Jan 6 1424 California Avenue $750 2br - 1113ft2 - (Klamath
Falls),http://klamath.craigslist.org/apa/5947977083.html,1424 California
Avenue $750 2br - 1113ft2 - (Klamath Falls) - (Klamath Falls),1424
California Avenue $750 2br - 1113ft2,Klamath
Falls,OR,kl,,house,750,1/6/2017,1/6/2017,2,no smoking,,,
Jan 11 1424 California Avenue $750 2br - 1113ft2 - (Klamath
Falls),http://klamath.craigslist.org/apa/5947977083.html,1424 California
Avenue $750 2br - 1113ft2 - (Klamath Falls) - (Klamath Falls),1424
California Avenue $750 2br -
1113ft2,,OR,kl,,house,750,1/11/2017,1/6/2017,2,no smoking,,,
"Jan 3 1838 Alma Drive Kelso, WA 98626 $550 1br - 600ft2 - (1838 Alma
Drive Kelso,
WA)",http://portland.craigslist.org/clk/apa/5937961608.html,"1838 Alma
Drive Kelso, WA 98626 $550 1br - 600ft2
RE: Namedtuples: some unexpected inconveniences
Roel Schroeven wrote, on Thursday, April 13, 2017 5:26 PM
>
> Gregory Ewing schreef op 13/04/2017 9:34:
> > Deborah Swanson wrote:
> >> Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >>
> >>> Personally I would immediately discard the header row
> once and for
> >>> all, not again and again on every operation.
> >> Well, perhaps, but I need the header row to stay in place to write
> >> the list to a csv when I'm done
> >
> > That's no problem, just write the header row separately.
> >
> > Do this at the beginning:
> >
> >header = [Record._make(fieldnames)]
> >records = [Record._make(row) for row in rows]
> >
> > and then to write out the file:
> >
> >writer = csv.writer(outputfile)
> >writer.writerow(header)
> >writer.writerows(records)
>
> I don't even think there's any need to store the field names anywhere
> else than in fieldnames. So unless I'm missing something,
> just do this
> at the beginning:
>
> fieldnames = next(rows)
> Record = namedtuple("Record", fieldnames)
> records = [Record._make(row) for row in rows]
>
> and this at the end:
>
> writer = csv.writer(outputfile)
> writer.writerow(fieldnames) # or writer.writerow(Record._fields)
> writer.writerows(records)
>
>
> --
> The saddest aspect of life right now is that science gathers
> knowledge faster than society gathers wisdom.
>-- Isaac Asimov
>
> Roel Schroeven
Thanks Roel. I'll try your version when I get the code reconstructed,
and that might take a few to several days. I'll try to get back to you
though on how it goes.
Read the previous messages if you want the sad story of what happened to
the original code.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Gregory Ewing wrote, on Thursday, April 13, 2017 1:14 AM
>
> Deborah Swanson wrote:
> > I don't exactly understand your point (2). If the
> namedtuple does not
> > have a label attribute, then getattr(record, label) will
> get the error
> > whether the name label holds the string 'label' or not.
>
> You sound rather confused. Maybe the following interactive
> session transcript will help.
>
> >>> from collections import namedtuple
> >>> record = namedtuple('record', 'alpha,beta')
> >>> r = record(1, 2)
> >>> r
> record(alpha=1, beta=2)
> >>> label = 'alpha'
> >>> getattr(r, label)
> 1
> >>> label = 'beta'
> >>> getattr(r, label)
> 2
> >>> label = 'gamma'
> >>> getattr(r, label)
> Traceback (most recent call last):
>File "", line 1, in
> AttributeError: 'record' object has no attribute 'gamma'
>
> Can you see what's happening here? The expression
>
> label
>
> is being evaluated, and whatever string it evaluates to is
> being used as the attribute name to look up.
>
> Now, I'm not sure exactly what you were doing to get the
> message "'record' object has no attribute 'label'". Here are
> a few possible ways to get that effect:
>
> >>> r.label
> Traceback (most recent call last):
>File "", line 1, in
> AttributeError: 'record' object has no attribute 'label'
>
> >>> getattr(r, 'label')
> Traceback (most recent call last):
>File "", line 1, in
> AttributeError: 'record' object has no attribute 'label'
>
> >>> label = 'label'
> >>> getattr(r, label)
> Traceback (most recent call last):
>File "", line 1, in
> AttributeError: 'record' object has no attribute 'label'
>
> Or maybe you did something else again. We would need to
> see your code in order to tell.
>
> --
> Greg
And it's reproducing the code that's the roadblock to all of these
issues.
Rest assured I will get to the bottom of this, or at least come back
with the code to ask more questions about it and let you see what I had.
I want to see what's going on here too.
Might be a day or two though.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Gregory Ewing wrote, on Thursday, April 13, 2017 12:34 AM > > Deborah Swanson wrote: > > Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM > > > >> Personally I would immediately discard the header row once and for > >> all, not again and again on every operation. > > > > Well, perhaps, but I need the header row to stay in place > to write the > > list to a csv when I'm done > > That's no problem, just write the header row separately. > > Do this at the beginning: > >header = [Record._make(fieldnames)] >records = [Record._make(row) for row in rows] > > and then to write out the file: > >writer = csv.writer(outputfile) >writer.writerow(header) >writer.writerows(records) > > > There might be a tiny performance edge in discarding the header row > > for the sort, but there would also be a hit to recreate it > at output > > time. > > It's not about performance, it's about keeping the code as > clean and simple as you can, thus making it easier to > understand and maintain. > > The general idea to take away from this is that it's almost > always best to arrange things so that a given collection > contains just one kind of data, so you can treat every > element of it in exactly the same way. > > -- > Greg That's good advice and I'll rewrite it that way, after I have the code I started with to answer the other questions. I certainly know I have a lot to learn about writing good code, and I can see that what you're suggesting is much cleaner than what I had. Thanks, Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Gregory Ewing wrote, on Thursday, April 13, 2017 12:36 AM > > If you want to be able to update your rows, you may find > this useful: > https://pypi.python.org/pypi/recordclass It's very similar to a namedtuple, but mutable. Looks like it should be a drop-in replacement. -- Greg Thanks Greg, I'll definitely take a look at it -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Gregory Ewing wrote, on Thursday, April 13, 2017 12:17 AM > > Deborah Swanson wrote: > > But I think you got it right in your last sentence below. > defaultdict > > copied them because they were immutable, > > No, definitely not. A defaultdict will never take it upon > itself to copy an object you give it, either as a key or a value. > > The copying, if any, must have occurred somewhere else, in > code that you didn't show us. > > Can you show us the actual code you used to attempt to > update the namedtuples? > > -- > Greg As I just told Peter, I just discovered earlier today that all of that code is lost, and it will take awhile to rewrite. And now I have several reasons to do so. I don't know how long it will take, but I will come back and produce the code that gave me this behavior. -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Thursday, April 13, 2017 12:17 AM
>
> Deborah Swanson wrote:
>
> > Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM
> >>
> >> Deborah Swanson wrote:
> >>
> >> > It's a small point, but I suspect getattr(record, label)
> >> would still
> >> > fail, even if label's value is 'label' and only 'label',
> but what's
> >> > the point of having a variable if it will only ever have
> just one
> >> > value?
> >>
> >> You are misunderstanding. Your getattr() call fails because you
have
> >>
> >> label = "label"
> >>
> >> burried somewhere in your code. As soon as you change that to
> >>
> >> label =
> >>
> >> the error will go away.
> >
> >
> > Yes, the error goes away, but now getattr(record, label) is useless
> > for processing field names, unless you want to write a line of code
> > for each one. (I have 17 field names, and forget about passing label
> > to a function.)
Uh-oh, I boobooed and misread what you wrote here.
> No, it's not useless:
>
> >>> from collections import namedtuple
> >>> T = namedtuple("T", "foo bar baz")
> >>> t = T(1, 2, 3)
> >>> for name in t._fields:
> ... print(name, "=", getattr(t, name))
> ...
> foo = 1
> bar = 2
> baz = 3
Wow. Ok, I can see that the specific circumstance I got the "object has
no attribute 'label' error was quite likely not due to using getattr()
with a variable for a namedtuple field name, and probably some other
factor was at work.
Unfortunately, when I shifted gears on the overall problem and abandoned
the strategy of making the group-by defaultdict, I renamed the project
file and started over, going back to the original list of namedtuples.
As a result, all the back versions of my code producing this error were
lost.
I've spent the better part of today rewriting the lost code, and I'm
nowhere near finished, and now my illness is ganging up on me again. So
anything further will have to wait til tomorrow.
I remain quite sure that at no point did I have the line
label = "label"
in my code, and I wouldn't even have thought of writing it because it's
so absurd in so many ways. Hopefully I can show you what I wrote soon,
and you can see for yourself.
> And as a special service here's a mutable datatype with sufficient
> namedtuple compatibility to replicate the above snippet:
>
> $ cat namedtuple_replacement.py
> def struct(name, wanted_columns):
> class Struct:
> _fields = __slots__ = wanted_columns.split()
>
> def __init__(self, *args):
> names = self.__slots__
> if len(args) != len(names):
> raise ValueError
> for name, value in zip(names, args):
> setattr(self, name, value)
>
> @classmethod
> def _make(cls, args):
> return cls(*args)
>
> def __repr__(self):
> names = self.__slots__
> return "{}({})".format(
> self.__class__.__name__,
> ", ".join("{}={!r}".format(n, getattr(self,
> n)) for n in
> names)
> )
>
> Struct.__name__ = name
> return Struct
>
> T = struct("T", "foo bar baz")
> t = T(1, 2, 3)
> print(t)
> for name in t._fields:
> print(name, "=", getattr(t, name))
> t.bar = 42
> print(t)
> $ python3 namedtuple_replacement.py
> T(foo=1, bar=2, baz=3)
> foo = 1
> bar = 2
> baz = 3
> T(foo=1, bar=42, baz=3)
Thank you for this datatype definition.
I won't take a serious look at it until I rewrite the code I lost and
get to the bottom of why getattr() got the attribute error, but once
that issue is resolved I will return to your mutable datatype with
namedtuple
compatibility (to some extent, I gather).
I apologize for the delay, but your simple getattr() example above
demands that I find out why it wasn't working for me before moving on
with the rest of this. And that will take some time. Probably not the 3
weeks it took me to get to the point where I was consistently seeing the
error, but it will be awhile. I'll come back to address these issues and
your datatype when I've got code to show what I did. (For my own sanity,
if no other reason.)
--
https://mail.python.org/mailman/listinfo/python-list
RE: Swiss Ephemeris
> > Rustom Mody wrote, on Monday, April 10, 2017 11:50 PM > > > > On Monday, April 10, 2017 at 11:26:47 AM UTC+5:30, Deborah Swanson > > wrote: > > > The great ancients were no less endowed with intelligence than we are, > > > they simply directed it to different ends. > > > > And just when I was convinced by the all-knowers that my gpa > > was a monkey you've spoilt my complacence > > Good! It's unhealthy the way modern folk strut around > thinking they're the smartest humans to ever walk this earth. > We've gone farther with technology than any other time or > culture, but invention (and innovation) is only one aspect of > intelligence. > > > > ... medical astrology... > > > > whether that is hooey or scepticism of it is hooey, I dont > > know [Yeah I genuinely don't know what that term means for you] > > I don't know that anyone does. I use a very strict > interpretation of the orginal rules that you won't by find > googling "medical astrology". (I know, I've tried, in the old > Google as well as the new.) There's no pretension to mystic > art in my form, but mine's a lot more accurate and > information rich, so far as I can see in the few writings > about it. I think concentrating on the actual and valid > relationships while ignoring all the mysticism yields more > useful results. I know the ancient Greeks were wed to their > gods and I forgive them for that. I just think they would > have done better without the mythology. > > > However you may be interested in > > http://blog.languager.org/2016/01/how-long.html > > which is a > motley collection of the incredible > > persistence of humans to erroneous ways and outlooks and > > their damaging consequences > > I think you also talk about the incredible persistence of > other concepts and perceptions, notably in music and > mathematics (which were always linked in earlier times). > > I would find your other examples of erroneous thinking a bit > skewed in lengths of time. Tofler was right in Future Shock. > We've accelerated our intellectual development since the > Middle Ages, though I don't think it's because we're any > smarter. I can't remember exactly when it was that the human > brain reached it's current size and mental capacity, but it > was shortly before the time of the ancients. Physiologically > we've changed very little since then, but the knowledge base > we've built on over time was what eventually caused the > acceleration. No single person in modern times is > intellectually capable of buiding the concepts we now use > from scratch. We stand on the shoulders of giants. > > > [Frank Admission: That list started with a discussion on this list > > where I > > suggested that OOP is already debunked hooey and that FP is > > the way forward for programming. To which Steven asked that > > since FP is at least 50 years old and has not got > > very far, what makes one think its going anywhere... > > To which I wondered... Is 50 years a long time? By what standard? > > Hence that list ] > > 50 years isn't that long, though you must consider the > accelerated times we're living in. LISP is likely doomed > though. It's chief claim to fame was AI, and it's unlikely to > reclaim its former glory, not with languages like Python > leading the charge. My only contact with LISP was from a > computer science professor in 1975, who literally raved about > how superior LISP was. I dunno. I was doing AI in PL1 then > and had several debates with this fellow. I don't remember > much of the substance of those debates, but I know he never > persuaded me that LISP was superior to PL1. > > Deborah > -- https://mail.python.org/mailman/listinfo/python-list
RE: Swiss Ephemeris
Rustom Mody wrote, on Monday, April 10, 2017 11:50 PM > > On Monday, April 10, 2017 at 11:26:47 AM UTC+5:30, Deborah Swanson wrote: > > The great ancients were no less endowed with intelligence than we are, > > they simply directed it to different ends. > > And just when I was convinced by the all-knowers that my gpa > was a monkey you've spoilt my complacence Good! It's unhealthy the way modern folk strut around thinking they're the smartest humans to ever walk this earth. We've gone farther with technology than any other time or culture, but invention (and innovation) is only one aspect of intelligence. > > ... medical astrology... > > whether that is hooey or scepticism of it is hooey, I dont > know [Yeah I genuinely don't know what that term means for you] I don't know that anyone does. I use a very strict interpretation of the orginal rules that you won't by find googling "medical astrology". (I know, I've tried, in the old Google as well as the new.) There's no pretension to mystic art in my form, but mine's a lot more accurate and information rich, so far as I can see in the few writings about it. I think concentrating on the actual and valid relationships while ignoring all the mysticism yields more useful results. I know the ancient Greeks were wed to their gods and I forgive them for that. I just think they would have done better without the mythology. > However you may be interested in > http://blog.languager.org/2016/01/how-long.html > which is a > motley collection of the incredible > persistence of humans to erroneous ways and outlooks and > their damaging consequences I think you also talk about the incredible persistence of other concepts and perceptions, notably in music and mathematics (which were always linked in earlier times). I would find your other examples of erroneous thinking a bit skewed in lengths of time. Tofler was right in Future Shock. We've accelerated our intellectual development since the Middle Ages, though I don't think it's because we're any smarter. I can't remember exactly when it was that the human brain reached it's current size and mental capacity, but it was shortly before the time of the ancients. Physiologically we've changed very little since then, but the knowledge base we've built on over time was what eventually caused the acceleration. No single person in modern times is intellectually capable of buiding the concepts we now use from scratch. We stand on the shoulders of giants. > [Frank Admission: That list started with a discussion on this list where I > suggested that OOP is already debunked hooey and that FP is > the way forward for programming. To which Steven asked that > since FP is at least 50 years old and has not got > very far, what makes one think its going anywhere... > To which I wondered... Is 50 years a long time? By what standard? > Hence that list ] 50 years isn't that long, though you must consider the accelerated times we're living in. LISP is likely doomed though. It's chief claim to fame was AI, and it's unlikely to reclaim its former glory, not with languages like Python leading the charge. My only contact with LISP was from a computer science professor in 1975, who literally raved about how superior LISP was. I dunno. I was doing AI in PL1 then and had several debates with this fellow. I don't remember much of the substance of those debates, but I know he never persuaded me that LISP was superior to PL1. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM > > Deborah Swanson wrote: > > > It's a small point, but I suspect getattr(record, label) > would still > > fail, even if label's value is 'label' and only 'label', but what's > > the point of having a variable if it will only ever have just one > > value? > > You are misunderstanding. Your getattr() call fails because you have > > label = "label" > > burried somewhere in your code. As soon as you change that to > > label = > > the error will go away. Yes, the error goes away, but now getattr(record, label) is useless for processing field names, unless you want to write a line of code for each one. (I have 17 field names, and forget about passing label to a function.) -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:30 PM
>
> Here you can see now
>
> from selenium.webdriver.firefox.firefox_profile import FirefoxProfile
> import random
> from selenium import webdriver
> from selenium.webdriver.common.keys import Keys
>
> browser.get('https://www.google.co.uk/search?q=Rashmi&oq=Rashm
> i&aqs=chrome..69i57j69i60l3.6857j0j1&sourceid=chrome&ie=UTF-8#
> q=Mobiles+in+london')
> time.sleep(5)
>
> try:
> p_links = browser.find_elements_by_css_selector(' div
> > h3 > a')
> url_list = []
> for urls in p_links:
> if "London" in urls.text:
>
> urls.get_attribute("href")
> url_list.append(urls)
> for links in url_list:
> browser.get(links)
> time.sleep(4)
> except:
> browser.close()
Ok, I'm sure you changed the search terms, don't know if you changed the
google url, but the code looks the same.
I'm headed away from the computer for the night, but try using a shorter
sleep time, like
time.sleep(1)
--
https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:05 PM > > Hi Deborah, >I checked again selecting css there found 11 URLS and I > printed it is printing all urls but it visits the first url not all.. Hmm. Sounds like you've changed your code in some way. Either changing the web page you're pointing to, changing the css selector or something I can't guess, because in your last msg yo said you were seeing just the opposite. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:05 PM > > Hi Deborah, >I checked again selecting css there found 11 URLS and I > printed it is printing all urls but it visits the first url not all.. I'm just guessing again, but time.sleep(4) could be too long a time to sleep, especially if you're on a fast network and you don't have many browser windows open before you run your code. It might be opening the first url and printing all the others and exiting the for loop before time.sleep(4) expires. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 11:03 PM > > from selenium.webdriver.firefox.firefox_profile import > FirefoxProfile import random from selenium import webdriver > from selenium.webdriver.common.keys import Keys Ok, that gives us a clue what you're working with, which will probably help with something. Since your code works, I'm guessing your use of selenium is probably ok. I'd be looking for structural issues in the HTML for reasons why you're not getting what you want to get. -- https://mail.python.org/mailman/listinfo/python-list
RE: Visit All URLs with selenium python
Nicole wrote, on Wednesday, April 12, 2017 9:49 PM
>
> browser.get('https://www.google.co.uk/search?q=Rashmi&oq=Rashm
> i&aqs=chrome..69i57j69i60l3.6857j0j1&sourceid=chrome&ie=UTF-8#
q=Rashmi+Custom+Tailors')
> time.sleep(5)
>
> try:
> p_links =
> browser.find_elements_by_css_selector('div > h3 > a')
> url_list = []
> for urls in p_links:
> if "Rashmi Custom Tailors" in urls.text:
>
> url = urls.get_attribute("href")
> url_list.append(url)
> for url in url_list:
> browser.get(url)
> time.sleep(4)
>
>
> it just visit first url not all .. Can anybody help how to fix that..
You don't say what module you're using and it would help to see the
"import ..." statement.
But there are a couple things I can think of that could be causing the
problem:
There's only one result with the exact phrase "Rashmi Custom
Tailors" on
the page.
or
The css_selector('div > h3 > a') only occurs for the first
result and
selectors for subsequent results are different. I've seen that
before. If
the div extends all the way down the list until after the last
result,
the results after the first one might have css_selector('h3 >
a'), but
I'm just guessing about how they might be different.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote, on Wednesday, April 12, 2017 4:29 PM > > Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM > > > > >> Indeed you cannot change the namedtuple's attributes. Like the > > >> "normal" tuple it is designed to be immutable. If you want changes in > > >> one list (the group) to appear in another (the original records) you > > >> need a mutable data type. > > > > > > Sadly, that does seem to be the correct conclusion here. > > > > Think hard if you really need the original list. > > It's possible you might transform the namedtuple into a > mutable type, and I didn't try that. But it seems like the > group-by defaultdict strategy would have to have a > significant performance edge to be worth it and you wouldn't > have any of the namedtuple properties to work with after the > transformation. I also ran into some trouble with your > algorithm that follows making the defaultdict, and I'm not > sure what value there would be in hashing through that. > Though I'm certainly willing to if you are. > > It worked to simply stay with the original list of > namedtuples to begin with. > > I remain grateful for your introduction to the collections > module. What a neat little package of tools! I know it's quick for this double-take, but it occurs to me that transforming to a mutable type isn't a performance evaluation at all. Filling in missing values is the last step before outputting the processed list, so it might not be necessary to work with namedtuples at that point. The algorithm to fill in the missing values for each group (which would no longer be namedtuples) in the defaultdict is something I'm back at the drawing board for. But it shouldn't be too hard. Haha, we'll see! -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM > > Deborah Swanson wrote: > > >> >value = getattr(record, label) > >> > >> That should work. > > > > We may agree that it *should* work, by an intuitive grasp of how it > > should work, but it doesn't. You get "object has no attribute 'label'. > > Only if the namedtuple > > (1) does not have a label attribute and > (2) the value of the name label is the string "label" > > In that case both > > label = "label" > getattr(record, label) > > and > > record.label > > will fail with the same AttributeError. The problem is *not* the dynamic > access through getattr(). Agreed, it's not getattr's fault. It's a small point, but I suspect getattr(record, label) would still fail, even if label's value is 'label' and only 'label', but what's the point of having a variable if it will only ever have just one value? The question would be whether the compiler (interpreter?) would look at getattr(record, label), evaluate label and see that there is a field named 'label', but I suspect it wouldn't take that many steps. It wants to see recordset.fieldname, and a bare "label" does not reference the object. I don't exactly understand your point (2). If the namedtuple does not have a label attribute, then getattr(record, label) will get the error whether the name label holds the string 'label' or not. And it wants to see recordset.fieldname, not just fieldname. But maybe I misunderstood what you were saying. This stuff is quite loopy to think about, at least for me it is. > >> Indeed you cannot change the namedtuple's attributes. Like the > >> "normal" tuple it is designed to be immutable. If you want changes in > >> one list (the group) to appear in another (the original records) you > >> need a mutable data type. > > > > Sadly, that does seem to be the correct conclusion here. > > Think hard if you really need the original list. It's possible you might transform the namedtuple into a mutable type, and I didn't try that. But it seems like the group-by defaultdict strategy would have to have a significant performance edge to be worth it and you wouldn't have any of the namedtuple properties to work with after the transformation. I also ran into some trouble with your algorithm that follows making the defaultdict, and I'm not sure what value there would be in hashing through that. Though I'm certainly willing to if you are. It worked to simply stay with the original list of namedtuples to begin with. I remain grateful for your introduction to the collections module. What a neat little package of tools! -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
>
> Deborah Swanson wrote:
>
> > I won't say the following points are categorically true, but I
became
> > convinced enough they were true in this instance that I abandoned
the
> > advised strategy. Which was to use defaultdict to group the list of
> > namedtuples by one of the fields for the purpose of determining
> > whether certain other fields in each group were either missing
values
> > or contained contradictory values.
> >
> > Are these bugs, or was there something I could have done to avoid
> > these problems? Or are they just things you need to know working
with
> > namedtuples?
> >
> > The list of namedtuples was created with:
> >
> > infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in
-
> > test.csv")
> > rows = csv.reader(infile)fieldnames = next(rows)
> > Record = namedtuple("Record", fieldnames)
> > records = [Record._make(fieldnames)]
> > records.extend(Record._make(row) for row in rows)
> > . . .
> > (many lines of field processing code)
> > . . .
> >
> > then the attempt to group the records by title:
> >
> > import operator
> > records[1:] = sorted(records[1:], key=operator.attrgetter("title",
> > "Date"))
>
> Personally I would immediately discard the header row once and for
all, not
> again and again on every operation.
Well, perhaps, but I need the header row to stay in place to write the
list to a csv when I'm done (which is why it's there in the first
place). There might be a tiny performance edge in discarding the header
row for the sort, but there would also be a hit to recreate it at output
time.
> > groups = defaultdict() for r in records[1:]:
> > # if the key doesn't exist, make a new group
> > if r.title not in groups.keys():
> > groups[r.title] = [r]
> > # if key (group) exists, append this record
> > else:
> > groups[r.title].append(r)
>
> You are not using the defaultdict the way it is intended; the
> groups can be built with
>
> groups = defaultdict(list)
> for r in records[1:]:
> groups[r.title].append(r)
Yes, going back to your original post I see now that's what you gave,
and it's probably why I noticed defaultdict's being characterized by
what you make the default to be. Too bad I lost track of that.
> > (Please note that this default dict will not automatically make new
> > keys when they are encountered, possibly because the keys of the
> > defaultdict are made from namedtuples and the values are
namedtuples.
> > So you have to include the step to make a new key when a key is not
> > found.)
> >
> > If you succeed in modifying records in a group, the dismaying thing
is
> > that the underlying records are not updated, making the entire
> > exercise totally pointless, which was a severe and unexpected
> > inconvenience.
> >
> > It looks like the values and the structure were only copied from the
> > original list of namedtuples to the defaultdict. The rows of the
> > grouped-by dict still behave like namedtuples, but they are no
longer
> > the same namedtuples as the original list of namedtuples. (I'm sure
I
> > didn't say that quite right, please correct me if you have better
> > words for it.)
>
> They should be the same namedtuple. Something is wrong with
> your actual code or your diagnosis or both.
Well, I didn't see them behaving as the same namedtuples, and I looked
hard at it, many different ways. If someone could point out the mistake
I might have made to get only copies of them or why they necessarily
would be the same namedtuples, I'd certainly look into it. Or better yet
some code that does the same thing and they remain the same ones.
(But I think you got it right in your last sentence below. defaultdict
copied them because they were immutable, leaving the original list
unchanged.)
> > It might be possible to complete the operation and then write out
the
> > groups of rows of namedtuples in the dict to a simple list of
> > namedtuples, discarding the original, but at the time I noticed that
> > modifying rows in a group didn't change the values in the original
> > list of namedtuples, I still had further to go with the dict of
> > groups, and it was looking easier by the minute to solve the
missing
> > values problem directly from the original list of namedtuples, so
> > that's what I did.
> >
> > If requested I can reproduce how I saw that the original list of
> > na
RE: Namedtuples: some unexpected inconveniences
> -Original Message-
> From: Python-list
> [mailto:python-list-bounces+python=deborahswanson.net@python.o
> rg] On Behalf Of MRAB
> Sent: Wednesday, April 12, 2017 1:42 PM
> To: python-list@python.org
> Subject: Re: Namedtuples: some unexpected inconveniences
>
>
> On 2017-04-12 20:57, Deborah Swanson wrote:
> > Are these bugs, or was there something I could have done to avoid
> > these problems? Or are they just things you need to know
> working with namedtuples?
> >
> > The list of namedtuples was created with:
> >
> > infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving
> 2017 in -
> > test.csv")
> > rows = csv.reader(infile)fieldnames = next(rows)
> > Record = namedtuple("Record", fieldnames)
> > records = [Record._make(fieldnames)]
> > records.extend(Record._make(row) for row in rows)
> > . . .
> > (many lines of field processing code)
> > . . .
> >
> > then the attempt to group the records by title:
> >
> > import operator
> > records[1:] = sorted(records[1:], key=operator.attrgetter("title",
> > "Date")) groups = defaultdict() for r in records[1:]:
> > # if the key doesn't exist, make a new group
> > if r.title not in groups.keys():
> > groups[r.title] = [r]
> > # if key (group) exists, append this record
> > else:
> > groups[r.title].append(r)
> >
> > (Please note that this default dict will not automatically make new
> > keys when they are encountered, possibly because the keys of the
> > defaultdict are made from namedtuples and the values are
> namedtuples.
> > So you have to include the step to make a new key when a key is not
> > found.)
MRAB said:
> The defaultdict _will_ work when you use it properly. :-)
>
> The line should be:
>
> groups = defaultdict(list)
>
> so that it'll make a new list every time a new key is
> automatically added.
Arg. Now I remember the thought crossing my mind early on, and noticing
that the characterizing property of a defaultdict was what you set the
default to be. Too bad I forgot that useful thought once I was entangled
with all those other problems.
Thanks for jogging that memory stuck in a hidey hole.
> Another point: namedtuples, as with normal tuples, are immutable; once
> created, you can't change an attribute. A dict might be a better bet.
Yes, namedtuples still being tuples was a point mentioned in passing by
someone, I think Steve D'Aprano, but I didn't immediately see that as
being the roadblock to accessing field values by variable. It does make
sense now though, although others on the list also didn't see it, so I'm
not feeling as bad about it as I could.
Namedtuples absolutely was the right data structure for two thirds of
this program. I only ran into trouble with it trying to do the
defaultdict group by thing. And it all turned out ok just by going back
to the original list.
Now, if I could understand why the namedtuples grouped by the
defaultdict were only copied instead of remaining the same namedtuples
as the list they were copied from, that should wrap this set of problems
up.
Many thanks again!
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Namedtuples: some unexpected inconveniences
I won't say the following points are categorically true, but I became
convinced enough they were true in this instance that I abandoned the
advised strategy. Which was to use defaultdict to group the list of
namedtuples by one of the fields for the purpose of determining whether
certain other fields in each group were either missing values or
contained contradictory values.
Are these bugs, or was there something I could have done to avoid these
problems? Or are they just things you need to know working with
namedtuples?
The list of namedtuples was created with:
infile = open("E:\\Coding projects\\Pycharm\\Moving\\Moving 2017 in -
test.csv")
rows = csv.reader(infile)fieldnames = next(rows)
Record = namedtuple("Record", fieldnames)
records = [Record._make(fieldnames)]
records.extend(Record._make(row) for row in rows)
. . .
(many lines of field processing code)
. . .
then the attempt to group the records by title:
import operator
records[1:] = sorted(records[1:], key=operator.attrgetter("title",
"Date")) groups = defaultdict() for r in records[1:]:
# if the key doesn't exist, make a new group
if r.title not in groups.keys():
groups[r.title] = [r]
# if key (group) exists, append this record
else:
groups[r.title].append(r)
(Please note that this default dict will not automatically make new keys
when they are encountered, possibly because the keys of the defaultdict
are made from namedtuples and the values are namedtuples. So you have to
include the step to make a new key when a key is not found.)
If you succeed in modifying records in a group, the dismaying thing is
that the underlying records are not updated, making the entire exercise
totally pointless, which was a severe and unexpected inconvenience.
It looks like the values and the structure were only copied from the
original list of namedtuples to the defaultdict. The rows of the
grouped-by dict still behave like namedtuples, but they are no longer
the same namedtuples as the original list of namedtuples. (I'm sure I
didn't say that quite right, please correct me if you have better words
for it.)
It might be possible to complete the operation and then write out the
groups of rows of namedtuples in the dict to a simple list of
namedtuples, discarding the original, but at the time I noticed that
modifying rows in a group didn't change the values in the original list
of namedtuples, I still had further to go with the dict of groups, and
it was looking easier by the minute to solve the missing values problem
directly from the original list of namedtuples, so that's what I did.
If requested I can reproduce how I saw that the original list of
namedtuples was not changed when I modified field values in group rows
of the dict, but it's lengthy and messy. It might be worthwhile though
if someone might see a mistake I made, though I found the same behavior
several different ways. Which was when I called it barking up the wrong
tree and quit trying to solve the problem that way.
Another inconvenience is that there appears to be no way to access field
values of a named tuple by variable, although I've had limited success
accessing by variable indices. However, direct attempts to do so, like:
values = {row[label] for row in group}
(where 'label' is a variable for the field names of a namedtuple)
gets "object has no attribute 'label'
or, where 'record' is a row in a list of namedtuples and 'label' is a
variable for the fieldnames of a namedtuple:
value = getattr(record, label)
setattr(record, label, value) also don't work.
You get the error 'object has no attribute 'label' every time.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Swiss Ephemeris
Hi Peter I'm willing to believe there's a correlation between planetary cycles and the stockmarket, if you say you see one. The question is whether this correlation has truth value significance, or whether it's just a set of coincidences. The correlation is interesting, but I fail to see the causal link, the reason why planetary cycles necessarily have a relationship with market movements, and without that all you have is coincidence. Though one could spend a great deal of time analyzing the correlation, I have low confidence that it would be a strong and reliable correlation. This has been the fate of many other misadventures in astrology, systems of belief built around weak and unreliable correlations that are sometimes right, but more often wrong, sad to say. I don't have Windows 7 or 10. Any chance there's source code for the addin? That's what I would be looking at anyway. ;) Best, Deborah Peter Henry wrote, on Monday, April 10, 2017 1:56 PM > > Hi Deborah > > Very few people would believe there is correlation between > planetary cycles and the stockmarket however this is known > to select few, for many years, I can also visually see > relationship on charts, however its hard to quantify statically > > http://astrologynewsservice.com/business/study-confirms-plan > ets-impact-stock-market-averages/ > > I'll forward the Excel addin later it works on Windows 7 and > require updating to Win10 > > The idea is to create a full and complete program in Python > only, that would import stock data, generate planetary > coordinates, pre process train then predict > > I'll keep you updated > > Peter > > > > On 10 Apr 2017 9:10 p.m., "Deborah Swanson" > > wrote: > > > Hi Peter, > > > > I would be interested in seeing your Excel addin with customized > > planetary settings. I'd be curious what these > customizations would be, > > though if they look useful I'd more likely be scavenging > the code to > > rewrite it in Python and add to what I already have, rather > than using > > the addin in Excel. The only thing not quite right about > what I have > > is the times, which are a smidge off. This could be due to > planetary > > anomalies, so I definitely would like to look at it. > > > > I totally agree with all you said about Python and more. I didn't > > start out in Python looking to replace Excel or to migrate my > > planetary project to it, those things just happened along > the way. But > > looking around to see what was new and what was better than > anything > > I'd done before, Python was a natural choice. > > > > I'll have to say though that I don't share your enthusiasm for > > modeling the market with planetary relationships, indeed any > > mathematical modelling of the market can easily be overall > wrong, and > > yet complex enough to engage the explorer endlessly. > > > > I've analyzed a couple of these schemes to draw that conclusion, > > though it's tentative at best. Obviously there are > mathematical models > > of the market that do work, but I really don't know anything about > > them. > > > > In this case though, I don't see the connection between planetary > > configurations and a pure physical aspect of the market for them to > > engage with. And as you may recall from somewhere, to establish > > causality you must produce the causal link between the two sets of > > events you're attempting to correlate. No matter how > stunning an array > > of coincidences might be, without producing the causal link > you really > > don't have anything. This is a key error that many who do > statistical > > analyses tend to overlook. > > > > I looked at your CSV, but I'm not sure what you would like > to add to > > it, probably because I'm totally unfamiliar with this type > of project. > > > > Best in your endeavors, > > > > Deborah > > > > > > Peter Henry wrote, on Monday, April 10, 2017 11:58 AM > > > > Hi Deborah, > > > > > > Thanks your reply and interest, > > > > > > A few years ago did create a Excel addin, that extracted planetary > > coordinates from the Swisseph source code and populated excel > > spreadsheet This Marco addin had customized planetary settings of > > which was useful > > > > > > Currently now learning to program in Python as it is flexible, > > popular for machine learning and data science. The idea the >
RE: Swiss Ephemeris
Hi Peter, I would be interested in seeing your Excel addin with customized planetary settings. I'd be curious what these customizations would be, though if they look useful I'd more likely be scavenging the code to rewrite it in Python and add to what I already have, rather than using the addin in Excel. The only thing not quite right about what I have is the times, which are a smidge off. This could be due to planetary anomalies, so I definitely would like to look at it. I totally agree with all you said about Python and more. I didn't start out in Python looking to replace Excel or to migrate my planetary project to it, those things just happened along the way. But looking around to see what was new and what was better than anything I'd done before, Python was a natural choice. I'll have to say though that I don't share your enthusiasm for modeling the market with planetary relationships, indeed any mathematical modelling of the market can easily be overall wrong, and yet complex enough to engage the explorer endlessly. I've analyzed a couple of these schemes to draw that conclusion, though it's tentative at best. Obviously there are mathematical models of the market that do work, but I really don't know anything about them. In this case though, I don't see the connection between planetary configurations and a pure physical aspect of the market for them to engage with. And as you may recall from somewhere, to establish causality you must produce the causal link between the two sets of events you're attempting to correlate. No matter how stunning an array of coincidences might be, without producing the causal link you really don't have anything. This is a key error that many who do statistical analyses tend to overlook. I looked at your CSV, but I'm not sure what you would like to add to it, probably because I'm totally unfamiliar with this type of project. Best in your endeavors, Deborah Peter Henry wrote, on Monday, April 10, 2017 11:58 AM Hi Deborah, Thanks your reply and interest, A few years ago did create a Excel addin, that extracted planetary coordinates from the Swisseph source code and populated excel spreadsheet This Marco addin had customized planetary settings of which was useful Currently now learning to program in Python as it is flexible, popular for machine learning and data science. The idea the planetary coordinate can help with timing stock commodity and Forex markets, as both freely trading markets and planetary movement adhere to natural law Neural networks can also assist in extracting relationship information between markets and planetary positions. Whilst waiting for a solution can you advise of an efficient way of producing a a CSV file similar to the file attached, only planetary data required Many thanks Peter On 10 April 2017 at 02:52, Deborah Swanson wrote: Peter Henry wrote, on Sunday, April 09, 2017 10:53 AM > > I have a package that has been altered to imported in to > python, however I tired to get is working but without success > I be missing something obvious > > The Swiss Ephemeris enable planetary coordinate to be > imported and used in your program > > Files access https://pypi.python.org/pypi/pyswisseph > > Many thanks in advance > > Peter I've also worked on the problem of getting sweph into Python and have mostly struck out so far myself. I found one reliable means to get sweph's planetary data into Python, but it's more or less a cheat. Nonetheless, if you want to see how much good it does you, try the Swiss Ephemeris Test Page at http://www.astro.com/swisseph/swetest.htm. If you can successfully formulate a query useful to your purposes, you can download a csv of results, read it into Python, and work from there. Right now I'm working on converting some Excel spreadsheets and Excel VBA I use into Python and recoding it all, using the CSVs for jumping off points. That works pretty well, except the times from swetest are off a bit and I haven't figured out why. But I'm concentrating on getting all my VBA code ported to Python, and will go back to getting bang on data from sweph after I have my code done. The first thing I tried was to get sweph's C source code into a free IDE, but that whole project went down in flames. You can read bits and pieces of that misadventure at the tail end of the "Python application launcher (for Python code)" thread. I found sweph's C source code at some link off "Programming interface to the Swiss Ephemeris" at http://www.astro.com/swisseph/swephprg.htm (or maybe it was on http://www.astro.com/swisseph/swephinfo_e.htm - I can't easily find it now, but the download link is in one of those two pages somewhere.) Then I tried picking through sweph's C source code, attempting to manually reproduce the logic and t
RE: Swiss Ephemeris
Fully recognizing that most of what you wrote was tongue-in-cheek, I just want to say that regardless of the wonders of modern medicine, it's a pity they learn so little about successful medicines other than their own. In other academic scientific disciplines such as physics and chemistry it's not uncommon to see history of science courses in the curriculum. But not in medicine. I learned what I know about ancient Greek science from a university physics professor, though I doubt he would ever have guessed that one of his students would someday breathe new life into that ancient science by attempting to ressurrect it. The great ancients were no less endowed with intelligence than we are, they simply directed it to different ends. Rick Johnson wrote, on Sunday, April 09, 2017 9:00 PM > > On Sunday, April 9, 2017 at 8:52:44 PM UTC-5, Deborah Swanson wrote: > > PS. I've been using medical astrology to look ahead at my medical > > condition for years in advance. And being off by a day or > so doesn't > > matter that much when you're looking at trends over the course of > > years and decades. I also have a little software widget to > look at the > > planetary data in graphical chart form at any particular > second, also > > based on sweph, which has been quite astoundingly accurate in > > following the rather complex kaleidoscope of my symptoms > > during the course of a day. (Though it doesn't do you a bit > > of good if you forget to look! Which is my entire > > motivation to get it encoded and available with a few > > clicks.) And it is quite useful to know in advance what > > will be happening when, and most importantly when it will > > stop. Knowledge is power! > > It's simply amazing what technology can do these days. And > with medical diagnosis now just a few clicks away, someone > really should tell those medical students to stop wasting > time and money at university. > > > Caveat. This kind of precision and accuracy is only found > > in the specific forms of astrology which relate to pure physical > > phenomena, and most of what you see these days masquerading as > > astrology is pure hooey, almost entirely invented on a > large scale in > > the Middle Ages and flowered in the Renaissance. > > Whadda coinicidence, as did alchemy! > > > By pure physical phenomena, which is the only phenomena > > that is at least debatably influenced by physical planetary > forces, I > > mean things like the moon's tides, sunspots, plant and > animal activity > > throughout the year, and supremely, the inner workings of the human > > body, the first wholly Western medicine devised by the > ancient Greeks. > > (The ancient Greek physicians are an excellent fallback if > > modern medicine is failing you - if you can find enough > > that remains today of their art.) > > Yeah, just uh, be sure to avoid te hemlock, mmmkay? ;-) > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Swiss Ephemeris
Peter Henry wrote, on Sunday, April 09, 2017 10:53 AM > > I have a package that has been altered to imported in to > python, however I tired to get is working but without success > I be missing something obvious > > The Swiss Ephemeris enable planetary coordinate to be > imported and used in your program > > Files access https://pypi.python.org/pypi/pyswisseph > > Many thanks in advance > > Peter I've also worked on the problem of getting sweph into Python and have mostly struck out so far myself. I found one reliable means to get sweph's planetary data into Python, but it's more or less a cheat. Nonetheless, if you want to see how much good it does you, try the Swiss Ephemeris Test Page at http://www.astro.com/swisseph/swetest.htm. If you can successfully formulate a query useful to your purposes, you can download a csv of results, read it into Python, and work from there. Right now I'm working on converting some Excel spreadsheets and Excel VBA I use into Python and recoding it all, using the CSVs for jumping off points. That works pretty well, except the times from swetest are off a bit and I haven't figured out why. But I'm concentrating on getting all my VBA code ported to Python, and will go back to getting bang on data from sweph after I have my code done. The first thing I tried was to get sweph's C source code into a free IDE, but that whole project went down in flames. You can read bits and pieces of that misadventure at the tail end of the "Python application launcher (for Python code)" thread. I found sweph's C source code at some link off "Programming interface to the Swiss Ephemeris" at http://www.astro.com/swisseph/swephprg.htm (or maybe it was on http://www.astro.com/swisseph/swephinfo_e.htm - I can't easily find it now, but the download link is in one of those two pages somewhere.) Then I tried picking through sweph's C source code, attempting to manually reproduce the logic and the calculations in Python. That was a highly qualified semi-success because the times were still off, but it essentially produces the most basic planetary data. The swetest output CSVs were more complete however, and easy to read the planetary data into Python from, so I'd pretty much abandoned efforts to "translate" the C source code. And now, all my efforts to leverage the C source code. Even if successful it would be a lot more time sunk into working with a language other than Python, which I likely wouldn't have a use for after this project is completed. However, I have seen bits here and there on this list that are at least interesting. Tim Chase mentioned in passing that he encapsulated C source code in a class, which may bear looking into. Lutz Horn also gave a link for building a Python module to add a C language library to Python, which also might be worth checking out: https://docs.python.org/3/extending/index.html (I changed the 2 to a 3 from the link he gave, but you can change it back to 2 if your working in a build of Python 2.) But many thanks for your pypi link to pyswisseph, which I will check out. I can reply to this thread after I give it a shot and tell you what I think of it. But like I said earlier, that won't be until all my Excel VBA code, which jumps off from the sweph bare planetary data, is ported to Python and working. Could be awhile yet. And if pyswisseph doesn't pan out, I'll likely work on refining the two methods I have for producing the planetary data, both of which are only lacking precisely accurate time data in my local time, and both are off by only 5-30 minutes. I easily limped along for years with my Excel spread sheets using the swetest CSVs for input, even though my times then were more than a day off. Good luck! (and this venture is a goodly portion of luck...) Deborah PS. I've been using medical astrology to look ahead at my medical condition for years in advance. And being off by a day or so doesn't matter that much when you're looking at trends over the course of years and decades. I also have a little software widget to look at the planetary data in graphical chart form at any particular second, also based on sweph, which has been quite astoundingly accurate in following the rather complex kaleidoscope of my symptoms during the course of a day. (Though it doesn't do you a bit of good if you forget to look! Which is my entire motivation to get it encoded and available with a few clicks.) And it is quite useful to know in advance what will be happening when, and most importantly when it will stop. Knowledge is power! Caveat. This kind of precision and accuracy is only found in the specific forms of astrology which relate to pure physical phenomena, and most of what you see these days masquerading as astrology is pure hooey, almost entirely invented on a large scale in the Middle Ages and flowered in the Renaissance. By pure physical phenomena, which is the only phenomena that is at least debatably influenced by physical planetary forces, I mean t
RE: Two variable dictionary comprehension
Rob Gaddi wrote, on Tuesday, April 04, 2017 3:56 PM > > On 04/04/2017 03:34 PM, Deborah Swanson wrote: > > Terry Reedy wrote, on Tuesday, April 04, 2017 11:04 AM > >> > >> I am sure that this is because list comprehensions were once thr only > >> comprehensions and that the index was not updated when the syntax and > >> code was. I opened issue 29981 "Update Index for set, dict, and > >> generator 'comprehensions'". > >> > >> -- > >> Terry Jan Reedy > > > > Thanks Terry. I does seem strange that there are so many types of > > comprehensions, yet under 'comprehensions' in the Index, you only see > > 'list'. And there are no entries for the other types, by their names. > > > > Deborah > > > > Does it seem... incomprehensible? > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. Ha ha! Indeed it does. Funny how 'comprehension' word forms so easily fall into puns. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Sorry I bailed on you last night, but you know it's bad when you can't
read anymore.
I read through this today and saw several things I really need to work
with more, especially dicts, sets, generators and the zip function. I've
used all of them in fairly typical forms, but it's the atypical ones
that throw me. And strangely enough, I've never seen dicts described as
having key:value syntax, although it's certainly true and clarifies a
lot in thinking about them.
The one thing you mentioned that was completely new to me was the use of
an if clause in a list comprehension, and I can see there being times
when that's exactly what you want to do. I'll have to try the other
types of comprehensions and see if this same grammar works in all of
them. It should. Interesting how computer languages seem to be a hybrid
of math and linguistics.
I added all of these concepts and code snippets to my study list. Thanks
again Steve. ;)
Deborah
Steve D'Aprano wrote, on Monday, April 03, 2017 6:05 PM
>
> On Tue, 4 Apr 2017 03:27 am, Deborah Swanson wrote:
>
> > I'll admit that both dictionaries and comprehensions are still a
> > little bit fuzzy to me, especially when I get away from the common
> > usages. This could be a good exercise to clarify some of the fuzzy
> > areas.
>
>
> As far as comprehensions go, how is your mathematics?
>
> If you remember your set builder notation from maths, list
> comprehensions are based on that.
>
> In maths, we say something like:
>
> {2n + 1 : 0 ≤ n ≤ 9}
>
> which might be read aloud as "the set of 2 times n, plus 1,
> such that n is between 0 and 9 inclusive".
>
> http://www.mathwords.com/s/set_builder_notation.htm
>
> A similar notation might be:
>
> {2n + 1 : n ∈ {1, 2, 3}}
>
> said as "the set of 2 times n, plus 1, such that n is an
> element of the set {1, 2, 3}".
>
>
> If you're a maths geek like me, this is second nature :-)
>
>
> Now, Python's list comprehension syntax is based on a similar
> notation, except we spell it out in words rather than
> symbols, using the familiar "for n in ..." syntax from
> for-loops instead of : "such that".
>
> {2*n + 1 for n in range(10)}
>
> {2*n + 1 for n in (1, 2, 3)}
>
>
> A few other differences:
>
> - list comprehensions use [ ] for the outermost brackets;
> - set and dict comprehensions use { };
> - generator expressions use ( ) (unless the parentheses can
> be implied).
>
> We're not restricted to mathematical expressions, and can use
> any Python expression we like:
>
> [value.method(arg)[1] for (value, arg) in zip(values, arguments)]
>
>
> translates roughly into this for-loop:
>
> result = []
> for (value, arg) in zip(values, arguments):
> result.append(value.method(arg)[1])
>
>
>
> Another difference is that comprehensions allow an "if" clause:
>
> [v.method(a)[1] for (v, a) in zip(values, arguments) if v is not None]
>
> translates something like:
>
>
> result = []
> for (v, a) in zip(values, arguments):
> if v is not None:
> result.append(v.method(a)[1])
>
>
> There's more, but that covers probably 98% of comprehension usage.
>
> And of course, remember that dict comprehensions use the same
> key:value syntax as ordinary dict "literals" (the official
> name is "dict display").
>
> result = {}
> for key, value in zip(keys, values):
> result[key] = value
>
>
> becomes
>
> result = {key:value for (key, value) in zip(keys, values)}
>
> although frankly that's better written as:
>
> dict(zip(keys, values))
>
>
>
> Hope this helps!
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered
> up, and sure enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Terry Reedy wrote, on Tuesday, April 04, 2017 11:04 AM > > On 4/3/2017 2:35 AM, Gregory Ewing wrote: > > Deborah Swanson wrote: > > > >> Oh, come on. That's a fairly obscure citation in the docs, > one that > >> would take a good deal of experience and time reading > through them to > >> know was there, > > > Having said that, the index of the Python docs could be > improved a bit > > in this area -- currently it only mentions "list" under > > "comprehension" (although the page it leads to discusses the other > > types as well). > > I am sure that this is because list comprehensions were once thr only > comprehensions and that the index was not updated when the syntax and > code was. I opened issue 29981 "Update Index for set, dict, and > generator 'comprehensions'". > > -- > Terry Jan Reedy Thanks Terry. I does seem strange that there are so many types of comprehensions, yet under 'comprehensions' in the Index, you only see 'list'. And there are no entries for the other types, by their names. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Thanks Steve for writing this, and I'll read it more carefully when my
illness gives my mind back to me.
I was actually a math major before I discovered computer science, and I
had to progress beyond machine language and assembler before I found the
subtle differences and more flexible boundaries of higher level
programming languages you talk about. I'm sure much of it's the same
with Python. They key I think will be in finding more of the logic in
Python, and then fleshing it out with more detail and choices. The core
logic wasn't taught to me in the courses I took, so I need to backfill
it now.
I look forward to studying what you've written here as soon as I can.
Deborah
Steve D'Aprano wrote, on Monday, April 03, 2017 6:05 PM
>
> On Tue, 4 Apr 2017 03:27 am, Deborah Swanson wrote:
>
> > I'll admit that both dictionaries and comprehensions are still a
> > little bit fuzzy to me, especially when I get away from the common
> > usages. This could be a good exercise to clarify some of the fuzzy
> > areas.
>
>
> As far as comprehensions go, how is your mathematics?
>
> If you remember your set builder notation from maths, list
> comprehensions are based on that.
>
> In maths, we say something like:
>
> {2n + 1 : 0 ≤ n ≤ 9}
>
> which might be read aloud as "the set of 2 times n, plus 1,
> such that n is between 0 and 9 inclusive".
>
> http://www.mathwords.com/s/set_builder_notation.htm
>
> A similar notation might be:
>
> {2n + 1 : n ∈ {1, 2, 3}}
>
> said as "the set of 2 times n, plus 1, such that n is an
> element of the set {1, 2, 3}".
>
>
> If you're a maths geek like me, this is second nature :-)
>
>
> Now, Python's list comprehension syntax is based on a similar
> notation, except we spell it out in words rather than
> symbols, using the familiar "for n in ..." syntax from
> for-loops instead of : "such that".
>
> {2*n + 1 for n in range(10)}
>
> {2*n + 1 for n in (1, 2, 3)}
>
>
> A few other differences:
>
> - list comprehensions use [ ] for the outermost brackets;
> - set and dict comprehensions use { };
> - generator expressions use ( ) (unless the parentheses can
> be implied).
>
> We're not restricted to mathematical expressions, and can use
> any Python expression we like:
>
> [value.method(arg)[1] for (value, arg) in zip(values, arguments)]
>
>
> translates roughly into this for-loop:
>
> result = []
> for (value, arg) in zip(values, arguments):
> result.append(value.method(arg)[1])
>
>
>
> Another difference is that comprehensions allow an "if" clause:
>
> [v.method(a)[1] for (v, a) in zip(values, arguments) if v is not None]
>
> translates something like:
>
>
> result = []
> for (v, a) in zip(values, arguments):
> if v is not None:
> result.append(v.method(a)[1])
>
>
> There's more, but that covers probably 98% of comprehension usage.
>
> And of course, remember that dict comprehensions use the same
> key:value syntax as ordinary dict "literals" (the official
> name is "dict display").
>
> result = {}
> for key, value in zip(keys, values):
> result[key] = value
>
>
> becomes
>
> result = {key:value for (key, value) in zip(keys, values)}
>
> although frankly that's better written as:
>
> dict(zip(keys, values))
>
>
>
> Hope this helps!
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered
> up, and sure enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Gregory Ewing wrote, on Monday, April 03, 2017 4:23 PM > > Deborah Swanson wrote: > > I'd > > imagine that the old Google would have returned a good 10 pages or > > more (probably a lot more) of urls containing the phrase "dict > > comprehension" or "dictionary comprehension". > > It still does, as far as I can see. I just googled for "dict > comprehension", and the vast majority of results in the first > 10 pages relate to Python. > > By page 20 it's starting to wander off a bit, but you can > hardly blame it for that. There *are* non-Python web pages > that mention the words "dict" and "comprehension", and how is > Google to know that you don't want those if you don't tell it? Yes, I searched on "python dict comprehension" because I'd gottion the idea somewhere that the "python" was necessary in this Brave New Google world. I'll remember to omit "python" in the future when searching for phrases most frequently found in Python. Boolean rules were so much easier to learn and remember. > > You used to be able to keep sifting through pages of results after the > > bulk of urls fitting your criteria had passed, and still find useful > > things to look at, sometimes at page 500 > > Seems to me Google was doing a rather *bad* job if you had > to wade through 500 pages of results to find what you wanted. > I would never have the patience to do that! Well, it helped if you used 100 search results per page and other various and sundry tools. But patience was good too. It depended how bad you wanted the answer and how good a skim reader you are. Now I rarely find anything I want unless I'm shopping for something to buy, but even then I have to wade through all the garbage results intended to entice the impulse buyer in me, which I ditched decades ago. > Anyhow, the reason Google got brought up was that you were > complaining about difficulty of finding things in the Python > docs. Google *does* turn up the relevant part of the docs in > the very first page of results, so being able to do a direct > text search on the docs wouldn't do any better. We can duke that out some other time. My illness is overcoming me fast though, so it won't be right away. Deborah > -- > Greg -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Gregory Ewing wrote, on Monday, April 03, 2017 4:23 PM > > Deborah Swanson wrote: > > All my guesses were based on the > > single variable (the most common type) examples I found. I just didn't > > think of putting a colon after 'label', and found nothing to suggest > > that's what I should do. > > Hmmm, I'm not sure what the docs could do to make that any > clearer. The key:value syntax is part of *every* dict > comprehension (it's the only thing that distinguishes a dict > comprehension from a set comprehension). I guess I saw a lot of examples that weren't clearly using the key:value syntax, and all of it was so unfamiliar, that pattern just didn't stand out to me. But it's starting to now, and that's the direction I need to go in for dict comprehensions. > > Despite my earlier words and protestations that I did look for two > > variable dict comprehensions, fairly diligently, I am taking what you > > said seriously. > > Don't feel too bad. Sometimes it's hard to know what to > google for, even for experienced people! Also it's hard for > doc writers to anticipate how less experienced people will > think. It wouldn't have occurred to me to use the phrase "two > variable dict comprehension" when writing documentation. Yes, I was pretty sure the terminology I phrased the question with wasn't correct, but I didn't know the right words to say, or where to look them up, so I just tried to be as descriptive as I could. But I accomplished my purpose in asking the question, even if it was poorly put, and I've received quite a bit of good information, the terminology I couldn't put my finger on, and some solid pointers of directions to go in the future. > Another thing it's important to be able to do is see through > to the principles behind things, and then use those > principles to solve new problems that aren't explicitly > covered in any docs or examples. Ah, yes, there's the rub. But it's true, from cooking to car mechanics to Python coding, the key is in becoming familiar with the subject, and hands on is the best teacher. (Yes, yes, we could have a discussion about the role of education, but I'll say that it's seeing it all in motion for yourself many times that seals the teaching into something you know and don't need to be told.) > The general principle behind all the forms of comprehension > is that they consist of a prototypical element, followed by > some clauses that generate values for that element. > > The syntax for the prototypical element mirrors that of the > corresponding display. So, for a dict comprehension, the > prototypical element has the form 'key:value', where 'key' > and 'value' are arbitrary expressions. From there, it's just > a matter of figuring out what to put into those expressions. > > In your case, another part of the puzzle is the fact that > you can unpack a tuple obtained from a for-loop into > variables. That's a general feature of for-loops, both > inside and outside of comprehensions, so you probably > won't find it mentioned explicitly under the heading of > dict comprehensions. > > > Maybe it would be worthwhile to scrape the whole mess and have it in > > searchable text form. > > The HTML Python docs have a "Search" box, although I haven't > really used it so I don't know how well it works. It sucks, in a phrase. You're presented with a list of web page titles, very few of which seem to have much to do with the Python language topic you type into the search box. If you're interested in theoretical dissertations you'll be pleased, but if you're looking for barebones mechanical descriptions of the language you'll be wasting your time, in my experience. > In my > experience, Google with a site search often works a lot > better than search functions provided by sites themselves. Yes, I used to use Google's site search on a regular basis but somehow got out of the habit. It likely can't be beat if you know which website will have the answer you're looking for, but the old Google truly shown at finding places you didn't already know about. > > I hope you won't be miffed though if I still come up empty handed and > > come back here to ask again. > > > > Deborah > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Thank you Nate, for all these sources to study. Python was very easy for me to learn in 2 online courses, but it's been all uphill since then. I've learned a lot and for that I'm grateful, but there's so much farther to go. I've appreciated our discussions, but I am in fact a very sick person and my illness has come back again tonight. I can probably reply to a few more posts and then you won't see me again for awhile. But many thanks again, and I will begin reading the material you suggested. Deborah Nathan Ernst wrote, on Monday, April 03, 2017 3:37 PM No worries, Deborah. Python is by most measurements a relatively easy/simple language to learn, but there are always the dusty corners. If you've not already, I recommend going through the online Python tutorial in it's entirety (https://docs.python.org/3/tutorial/index.html). After that, learn the language syntax that wasn't covered in the tutorial by reading the Language Reference (https://docs.python.org/3/reference/index.html). The tutorial should be fairly easy for a straight beginner to follow. The language reference assumes a little higher-level understanding of programming language grammar. The Python Language Reference uses a modified BNF syntax (BNF being Backus-Naur form. You can read about BNF at https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form). To be honest, I'm not sure what modifications Python uses to BNF, maybe someone else can shed some light (or skin) on it. After you'd done those, peruse the standard library. I don't recommend deep reading there at this point, but at least a cursory reading so you're cognizant of libraries that are built-in that may help do things may you want to do now, or in the future (i.e. make a web request, parse JSON or XML, handle datetimes). Remember: Python comes with batteries included. -Nate On Mon, Apr 3, 2017 at 5:09 PM, Deborah Swanson wrote: Nathan Ernst wrote, on April 03, 2017 1:59 PM > > I was a bit surprised when I looked at the language reference > for 3.6.x. I expected there'd be a direct link to > comprehensions, but there's not. > > You have to know what you're looking for: > > 6.2.5: List Displays > 6.2.6: Set Displays > 6.2.7: Dictionary Displays > > And, then, click on the appropriate element of the sub > grammar to find the appropriate syntax. > > So, it took me about 30 seconds to find the appropriate > grammars, when I expected it'd only take about 5 seconds, > since I'm very familiar with the python docs & how the > grammar documentation is laid out. I can fully understand > how someone less familiar with the documentation might have a > harder time finding the grammar than I did. > > FWIW, If one was completely new to Python, even knowing the > syntax is known as a "comprehension" might be unknown. I > certainly didn't know what a comprehension was when I was > learning Python. A coworker showed me, some 13 years ago. > > Regards, > Nate Thanks Nate, for your comprehension of the plight of many, if not most, newish Python coders. And it certainly doesn't help to ask the list to fill in some of the holes and be met with criticism for asking, but I digress. It is what it is. Before I started reading the list a few months ago, I'd heard of list comprehensions in an article I'd read, and hardly understood the gist of it. But look at me now Ma, I've learned not only how to use list comprehensions but also a small tribe of other kinds of comprehensions! (If there's a moral to this story, heck if I know exactly what it is. "Keep on trying" is as good as any.) Deborah > On Mon, Apr 3, 2017 at 3:47 PM, Jerry Hill > wrote: > > > On Mon, Apr 3, 2017 at 10:30 AM, Deborah Swanson > > wrote: > > > Regular updates as the docs are updated would be a good idea too. > > > It's obvious that today's Google isn't up to it, although > it occurs > > > to me that I haven't tried Google's site search on python.org. > > > > So, when you search google for the phrase "dict comprehension" or > > "dictionary comprehension", nothing useful comes up for > you? When I > > search either of those phrases, I get lots of useful > results, all of > > which spell out how to do what you were originally asking about. I > > know Google search results are skewed by past usage, but > I'm surprised > > that you didn't find anything useful in the first couple of search > > results. > > > > When I do a search for 'dict comprehension' I get a boxed result > > linking to PEP 274 as the first hit, then two Stack Overflow > > questions, both of which demonstrate how t
RE: Two variable dictionary comprehension
Nathan Ernst wrote, on April 03, 2017 1:59 PM > > I was a bit surprised when I looked at the language reference > for 3.6.x. I expected there'd be a direct link to > comprehensions, but there's not. > > You have to know what you're looking for: > > 6.2.5: List Displays > 6.2.6: Set Displays > 6.2.7: Dictionary Displays > > And, then, click on the appropriate element of the sub > grammar to find the appropriate syntax. > > So, it took me about 30 seconds to find the appropriate > grammars, when I expected it'd only take about 5 seconds, > since I'm very familiar with the python docs & how the > grammar documentation is laid out. I can fully understand > how someone less familiar with the documentation might have a > harder time finding the grammar than I did. > > FWIW, If one was completely new to Python, even knowing the > syntax is known as a "comprehension" might be unknown. I > certainly didn't know what a comprehension was when I was > learning Python. A coworker showed me, some 13 years ago. > > Regards, > Nate Thanks Nate, for your comprehension of the plight of many, if not most, newish Python coders. And it certainly doesn't help to ask the list to fill in some of the holes and be met with criticism for asking, but I digress. It is what it is. Before I started reading the list a few months ago, I'd heard of list comprehensions in an article I'd read, and hardly understood the gist of it. But look at me now Ma, I've learned not only how to use list comprehensions but also a small tribe of other kinds of comprehensions! (If there's a moral to this story, heck if I know exactly what it is. "Keep on trying" is as good as any.) Deborah > On Mon, Apr 3, 2017 at 3:47 PM, Jerry Hill > wrote: > > > On Mon, Apr 3, 2017 at 10:30 AM, Deborah Swanson > > wrote: > > > Regular updates as the docs are updated would be a good idea too. > > > It's obvious that today's Google isn't up to it, although > it occurs > > > to me that I haven't tried Google's site search on python.org. > > > > So, when you search google for the phrase "dict comprehension" or > > "dictionary comprehension", nothing useful comes up for > you? When I > > search either of those phrases, I get lots of useful > results, all of > > which spell out how to do what you were originally asking about. I > > know Google search results are skewed by past usage, but > I'm surprised > > that you didn't find anything useful in the first couple of search > > results. > > > > When I do a search for 'dict comprehension' I get a boxed result > > linking to PEP 274 as the first hit, then two Stack Overflow > > questions, both of which demonstrate how to do dictionary > > comprehensions. Following that is another link to PEP 274, > a link to > > the Python docs on data structures (which does talk about dict > > comprehensions, but it's way down on the page), and then links to a > > bunch of tutorials. If you had to judge based on my search > results, > > Google does a fine job of answering python questions, at least when > > you already know the key phrase to look for. > > > > -- > > Jerry > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Jerry Hill wrote, on April 03, 2017 1:48 PM > > On Mon, Apr 3, 2017 at 10:30 AM, Deborah Swanson > wrote: > > Regular updates as the docs are updated would be a good > idea too. It's > > obvious that today's Google isn't up to it, although it > occurs to me > > that I haven't tried Google's site search on python.org. > > So, when you search google for the phrase "dict > comprehension" or "dictionary comprehension", nothing useful > comes up for you? When I search either of those phrases, I > get lots of useful results, all of which spell out how to do > what you were originally asking about. I know Google search > results are skewed by past usage, but I'm surprised that you > didn't find anything useful in the first couple of search results. > > When I do a search for 'dict comprehension' I get a boxed > result linking to PEP 274 as the first hit, then two Stack > Overflow questions, both of which demonstrate how to do > dictionary comprehensions. Following that is another link to > PEP 274, a link to the Python docs on data structures (which > does talk about dict comprehensions, but it's way down on the > page), and then links to a bunch of tutorials. If you had to > judge based on my search results, Google does a fine job of > answering python questions, at least when you already know > the key phrase to look for. > > -- > Jerry Ah, but did you actually try to use the proposed solutions on the two stackoverflow pages? It's been several weeks now, but I did, and neither of those two examples fit my situation, which is why I ended up writing my own, and unsatisfactorily at that. I'm sorry you think the current edition of Google does such a fine job. Has it really been that many years ago that the results Google returned from a properly formatted boolean search were really useful? I'd imagine that the old Google would have returned a good 10 pages or more (probably a lot more) of urls containing the phrase "dict comprehension" or "dictionary comprehension". in which you'd find a rich variety of specific situations to glean through. (You wouldn't have needed to include "python" in the search phrase, since no other programming language that I know of, or other English usage for that matter, has dict comprehensions.) Nowadays Google just comes up with a mere handful of sorta appropriate urls, and rarely do I find exactly what I'm looking for. And usually there's nothing related to all your search terms after a page or two of results. You used to be able to keep sifting through pages of results after the bulk of urls fitting your criteria had passed, and still find useful things to look at, sometimes at page 500 or even much, much farther down the list. It really paid to comb through them all, especially if you didn't find exactly what you wanted in the early batch. But giving users the choice among tens or hundreds of similar pages (fewer if you specify 100 results per page) doesn't give Google as much grist for the advertising mill to pump out at the users, hence the present day useless mess. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Rob Gaddi wrote, on April 03, 2017 10:38 AM
>
> On 04/03/2017 10:27 AM, Deborah Swanson wrote:
> > Dennis Lee Bieber wrote, on April 03, 2017 9:35 AM
> >>
> >> On Mon, 3 Apr 2017 07:30:40 -0700, "Deborah Swanson"
> >> declaimed the following:
> >>
> >>>
> >>> Clearly there's more to be found in nooks, crannies and byways in
the
> >>> docs than you'll get to from the given pointers in the index.
Maybe it
> >>> would be worthwhile to scrape the whole mess and have it in
searchable
> >>> text form. Another thing Python would be the right tool for the
job
> >>> for. Regular updates as the docs are updated would be a good idea
too.
> >>> It's obvious that today's Google isn't up to it, although it
occurs to
> >>> me that I haven't tried Google's site search on python.org.
> >>>
> >>On Windows, the (at least, for ActiveState releases)
documentation
> >> is available in Windows Help format -- though I'll admit the "free
> >> text search" leaves a lot to be desired...
> >>
> >>"dict comprehension" didn't find anything obvious; "dictionary
> >> comprehension" brought up PEP 274 (note: I still use 2.7 as main
> >> version).
> >>
> >> -=-=-=-=-=-
> >> Semantics
> >> The semantics of dict comprehensions can actually be
demonstrated
> >> in stock Python 2.2, by passing a list comprehension to the
> >> builtin dictionary constructor:
> >>
> >> >>> dict([(i, chr(65+i)) for i in range(4)])
> >>
> >> is semantically equivalent to
> >>
> >> >>> {i : chr(65+i) for i in range(4)}
> >>
> >> The dictionary constructor approach has two dictinct
disadvantages
> >> from the proposed syntax though. First, it isn't as legible as
a
> >> dict comprehension. Second, it forces the programmer to create
an
> >> in-core list object first, which could be expensive.
> >>
> >> -=-=-=-=-=-
> >> --
> >>Wulfraed Dennis Lee Bieber AF6VN
> >> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
> >
> > It would be interesting to play around with different list
> > comprehensions than the one they've shown.
> >
> > I'll admit that both dictionaries and comprehensions are still a
> > little bit fuzzy to me, especially when I get away from the common
> > usages. This could be a good exercise to clarify some of the fuzzy
> > areas.
> >
> > Deborah
> >
>
> And don't forget
>dict_comp : { k:v for (k,v) in kv_provider }
>set_comp : { item for item in item_provider }
>set_of_tuples_comp : { (k,v) for (k,v) in kv_provider }
>
> Just to make things more complicated.
>
> --
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order. See above to fix.
Added to my list of comprehension types, thank you.
I'm thinking it would also be good to include the PEPs in my searchable
Python reference. Just making the collection and browsing through it
would be highly instructive.
But, if Larry Page and Sergey Brin could tinker around in their dorm
rooms (or wherever they lived then) and they made the first Google (the
first search engine?) to boolean search the World Wide Web, it shouldn't
be so awfully hard to make a collection of Python docs that's boolean
searchable.
I haven't seen a search method for text that comes anywhere near boolean
search's completeness in returning results (though I'm happy to take
suggestions).
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Dennis Lee Bieber wrote, on April 03, 2017 9:35 AM
>
> On Mon, 3 Apr 2017 07:30:40 -0700, "Deborah Swanson"
> declaimed the following:
>
> >
> >Clearly there's more to be found in nooks, crannies and
> byways in the
> >docs than you'll get to from the given pointers in the
> index. Maybe it
> >would be worthwhile to scrape the whole mess and have it in
> searchable
> >text form. Another thing Python would be the right tool for the job
> >for. Regular updates as the docs are updated would be a good
> idea too.
> >It's obvious that today's Google isn't up to it, although it
> occurs to
> >me that I haven't tried Google's site search on python.org.
> >
> On Windows, the (at least, for ActiveState releases)
> documentation is available in Windows Help format -- though
> I'll admit the "free text search" leaves a lot to be desired...
>
> "dict comprehension" didn't find anything obvious;
> "dictionary comprehension" brought up PEP 274 (note: I still
> use 2.7 as main version).
>
> -=-=-=-=-=-
> Semantics
> The semantics of dict comprehensions can actually be demonstrated
> in stock Python 2.2, by passing a list comprehension to the
> builtin dictionary constructor:
>
> >>> dict([(i, chr(65+i)) for i in range(4)])
>
> is semantically equivalent to
>
> >>> {i : chr(65+i) for i in range(4)}
>
> The dictionary constructor approach has two dictinct disadvantages
> from the proposed syntax though. First, it isn't as legible as a
> dict comprehension. Second, it forces the programmer to create an
> in-core list object first, which could be expensive.
>
> -=-=-=-=-=-
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
It would be interesting to play around with different list
comprehensions than the one they've shown.
I'll admit that both dictionaries and comprehensions are still a little
bit fuzzy to me, especially when I get away from the common usages. This
could be a good exercise to clarify some of the fuzzy areas.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Gregory Ewing wrote, on April 02, 2017 11:35 PM > > Deborah Swanson wrote: > > > Oh, come on. That's a fairly obscure citation in the docs, one that > > would take a good deal of experience and time reading > through them to > > know was there, > > You seemed to know that there was something called a "dict > comprehension". Googling for "python 3 dict comprehension" > gives me a link to an example of one in the docs as the second result. > > The first result is a page in Dive Into Python containing > a section on dict comprehensions. > > Part of being a good programmer is knowing how to track > down the information you need! > > Having said that, the index of the Python docs could be > improved a bit in this area -- currently it only mentions > "list" under "comprehension" (although the page it leads to > discusses the other types as well). > > -- > Greg Despite my earlier words and protestations that I did look for two variable dict comprehensions, fairly diligently, I am taking what you said seriously. Obviously I shouldn't expect to find handy and recognizable entries in the index for everything I might want to find in the docs, and I plan to spend more time browsing around. Clearly there's more to be found in nooks, crannies and byways in the docs than you'll get to from the given pointers in the index. Maybe it would be worthwhile to scrape the whole mess and have it in searchable text form. Another thing Python would be the right tool for the job for. Regular updates as the docs are updated would be a good idea too. It's obvious that today's Google isn't up to it, although it occurs to me that I haven't tried Google's site search on python.org. I hope you won't be miffed though if I still come up empty handed and come back here to ask again. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Ben Finney wrote. on April 02, 2017 7:41 PM > > "Deborah Swanson" writes: > > > Chris Angelico wrote, on April 02, 2017 6:37 PM > > > > > > On Mon, Apr 3, 2017 at 11:26 AM, Deborah Swanson > > > > Maybe I'm having another "dumb day" [.] > > > > Well, wouldncha know it, I never tried using a colon. That's what I > > get for just trying to guess. > > Yes, guessing *is* dumb when the reference documentation is > available > https://docs.python.org/3/reference/expressions.html#disp > lays-for-lists-sets-and-dictionaries>. > I was sure you'd have been reading the manual before > guessing, but I'll know better in future :-) > > -- > \ "A computer once beat me at chess, but it was no > match for me | > `\ at kick boxing." > -Emo Philips | > _o__) > | > Ben Finney > Oh, come on. That's a fairly obscure citation in the docs, one that would take a good deal of experience and time reading through them to know was there, experience and years with Python that I don't have. But you knew that ... ;) Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Ben Finney wrote, on April 02, 2017 6:38 PM
>
> "Deborah Swanson" writes:
>
> > It seems like this should be easy to rewrite as a dict
> comprehension:
> >
> > records_idx = {}
> > for idx, label in enumerate(records[0]):
> > records_idx[label] = idx
>
> How about this::
>
> records_idx = {
> label: idx
> for (idx, label) in enumerate(collection_of_labels)
> }
>
> You may have tripped on the ambiguity of the comma in its
> surrounding context. I always prefer to put parens around the
> items I intend to be comma-separated, to remove that ambiguity.
>
> --
> \"[It's] best to confuse only one issue at a time."
> -Brian W. |
> `\ Kernighan, Dennis M. Ritchie, _The C programming
> language_, 1988 |
> _o__)
> |
> Ben Finney
That's a neat way to think about the problem. Me, I was guessing all the
way, and pleasantly surprised when the 3-statement concoction I came up
with worked.
Thanks Ben!
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
RE: Two variable dictionary comprehension
Chris Angelico wrote, on April 02, 2017 6:37 PM
>
> On Mon, Apr 3, 2017 at 11:26 AM, Deborah Swanson
> wrote:
> > It seems like this should be easy to rewrite as a dict
> comprehension:
> >
> > records_idx = {}
> > for idx, label in enumerate(records[0]):
> > records_idx[label] = idx
> >
> > Maybe I'm having another "dumb day", or maybe I've just been
> > struggling with this (larger) problem for too long, but eveything I
> > try to get an equivalent dict comprehension for the 3 lines above is
> > not working.
>
> Should be this:
>
> records_idx = {label: idx for idx, label in enumerate(records[0])}
>
> That's a direct translation of your code.
>
> ChrisA
Well, wouldncha know it, I never tried using a colon. That's what I get
for just trying to guess.
Thanks Chris
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Two variable dictionary comprehension
It seems like this should be easy to rewrite as a dict comprehension:
records_idx = {}
for idx, label in enumerate(records[0]):
records_idx[label] = idx
Maybe I'm having another "dumb day", or maybe I've just been struggling
with this (larger) problem for too long, but eveything I try to get an
equivalent dict comprehension for the 3 lines above is not working.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Developing a Python JIT and have trouble
Yuheng Zou wrote, on Friday, March 31, 2017 6:52 AM
>
> I am building a Python JIT, so I want to change the
> interp->eval_frame to my own function.
>
> I built a C++ library which contains EvalFrame function, and
> then use dlopen and dlsym to use it. It looks like this:
>
> extern "C" PyObject *EvalFrame(PyFrameObject *f, int throwflag) {
> return _PyEval_EvalFrameDefault(f, throwflag);
> }
> I added following code to Python/pylifecycle.c at function
> _Py_InitializeEx_Private(Python version is 3.6.1):
>
> void *pyjit = NULL;
> pyjit = dlopen("../cmake-build-debug/libPubbon.dylib", 0);
> if (pyjit != NULL) {
> interp->eval_frame = (_PyFrameEvalFunction)dlsym(pyjit,
> "EvalFrame");
> //interp->eval_frame = _PyEval_EvalFrameDefault;
> }
> Then something strange happened. I used LLDB to trace the
> variables. When it ran at EvalFrame, the address of f pointer
> didn't change, but f->f_lineno changed.
>
> Then when I ran python.exe, I got Segmentation Fault.
>
> Why the address of the pointer didn't change, but the context change?
>
> I am working on Mac OS X and Python 3.6.1. I want to know how
> to replace _PyEval_EvalFrameDefault in interp->eval_frame
> with my own function.
Hi Yuheng,
There might be some C coders on this list, maybe even a few who are
proficient in both C & Python. But this list is predominantly made up of
Python coders, and you may not get a reply. Personally, I don't know C
well enough nor am I familiar with the EvalFrame you mention to respond
to your question.
Shiboya
--
https://mail.python.org/mailman/listinfo/python-list
RE: Using/compiling pyuno with Python 3.6
filtered wrote, on March 27, 2017 9:09 PM > > Sorry but all your answers are pointless. > > I clearly asked about compiling PyUno MYSELF with a > self-compiled Python 3.6.1 installation. Is this so hard to > understand? Why do you give unrelated comments to a clear > questions? Sometimes it is better to be quiet. > > -aj If you really only wanted to know how to compile PyUno with a self-compiled Python 3.6.1 installation, it muddied the waters considerably that you first went on at length about your difficulties importing PyUno. It appeared that your main objective was to have an importable installation of PyUno, and it would have been better to omit the error details if all you wanted to know is how to compile it. Maybe not as clear a question as you imagine. > 2017-03-28 5:49 GMT+02:00 Michael Torrie : > > > On 03/27/2017 09:13 PM, Jim wrote: > > > I don't know if this is of any help but I am running Mint 18 with > > > Python 3.5 and I have a package installed called > python3-uno which > > > is described as "Python-UNO bridge". Maybe CentOS has a similarly > > > name package. > > > > You're right. In fact it looks like LibreOffice 5.3 at least ships > > with Python 3.5 as part of the package, and comes with > pyuno as part > > of that. Try running the python binary from the LibreOffice install > > directory (on my machine that is > /opt/libreoffice5.3/program/python). > > I'm not sure how to work with pyuno outside of the > LO-shipped python. > > > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Using/compiling pyuno with Python 3.6
filtered wrote, on Monday, March 27, 2017 4:41 AM > > I am running CentOS 7.1 with LibreOffice 5.0.6.2. > > I have installed the official pyuno package from CentOS. > > I installed Python 3.6.1 from the sources and now I am trying > to import pyuno which fails with > > aj...@dev.zopyx.com:~/src/docx> bin/python > Python 3.6.1 (default, Mar 27 2017, 13:27:24) > [GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux > > aj...@dev.zopyx.com:~/src/docx> bin/python -c "import uno" > Traceback (most recent call last): File "", line 1, > in File "/home/ajung/src/docx/uno.py", line 24, in >import pyuno > ImportError: dynamic module does not define module export function > (PyInit_pyuno) > > Is there a straight forward way for compiling pyuno myself? I > could not find any official documentation, links to various > posts are older than 5 years... > > Andreas I have no idea how to compile pyuno from sources. But if I were in your place, I'd look for other repositories that might have pyuno. It's been awhile since I had a Linux machine (it was also CentOS) and I generally found multiple repositories to try when the standard one failed. -- https://mail.python.org/mailman/listinfo/python-list
RE: why and how to run forever and debug when error in for proc in psutil.process_iter()?
Someone here can probably help you, but they'll need your Python
version, operating system, and full traceback. They get tired of saying
so.
In this case, the full traceback is needed to see what went wrong and
when (after which statements).
Ho Yeung Lee wrote, on Saturday, March 25, 2017 1:38 AM
>
> expect below to run forever and keep running a fixed number
> of thread in python
>
> would like to kill tasks when process connect internet except
> chrome and explorer.exe
>
> i do this because MalwareBytes can not disconnect these
> existing trojan when my notebook connect internet
>
> after run a few minutes, the program stopped, but i have
> already kept create process, why the whole program end?
>
> why and how to debug when error in for proc in psutil.process_iter()?
>
>
> import os
> import psutil
> import multiprocessing
> import time
> import sys
>
> def cleantask():
> p = os.popen("netstat -ano")
> while 1:
> line = p.readline()
> if "TCP" in line or "UDP" in line:
> linelist = line.split()
> if len(linelist) > 4:
> if "LISTEN" in str(linelist[3]):
> for proc in psutil.process_iter():
> try:
> if "pop" not in str(proc.name).tolower():
> os.system("taskkill /f /pid
> "+str(proc._pid))
> except:
> dummy = 1
> #print "Unexpected error:",
> sys.exc_info()[0]
> #print "Unexpected error:",
> sys.exc_info()[1]
> if "ESTABLISHED" in str(linelist[3]):
> if "127.0.0.1" not in str(linelist[2]):
> for proc in psutil.process_iter():
> try:
> if str(linelist[4]) in
> str(proc._pid):
>
> print(str(linelist[2])+","+str(linelist[4])+","+proc.name)
> if "111.221" not in
> str(linelist[2]) and "explorer.exe" not in str(proc.name).tolower():
> os.system("taskkill /f
> /pid "+str(proc._pid))
> except:
> dummy = 1
> #print "Unexpected error:",
> sys.exc_info()[0]
> #print "Unexpected error:",
> sys.exc_info()[1]
> print(line)
> if not line: break
>
> if __name__ == '__main__':
> print("main")
> try:
> numberofrunning = 0
> plist = []
> for ii in range(0,5):
> p = multiprocessing.Process(target=cleantask(), args=(0,))
> p.start()
> plist.append(p)
> numberofrunning = numberofrunning + 1
> time.sleep(1)
> for pp in plist:
> pp.join()
> if pp.is_alive() == False:
> numberofrunning = numberofrunning - 1
> plist.remove(pp)
> if numberofrunning > 10:
> print "more than 10 process"
> else:
> print("number of process = " + str(numberofrunning))
> if numberofrunning <= 5:
> p =
> multiprocessing.Process(target=cleantask(), args=(0,))
> p.start()
> plist.append(p)
> numberofrunning = numberofrunning + 1
> time.sleep(1)
> except:
> print "Unexpected error:", sys.exc_info()[0]
> print "Unexpected error:", sys.exc_info()[1]
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
RE: should i kill these two process with python?
Chris Angelico wrote, on Saturday, March 25, 2017 1:53 AM > > On Sat, Mar 25, 2017 at 7:41 PM, Ho Yeung Lee > wrote: > > TCP127.0.0.1:1663 127.0.0.1:28091 > ESTABLISHED 9900 > > TCP127.0.0.1:28091127.0.0.1:1663 > ESTABLISHED 9532 > > > > above two process connect to itself, named ismagent and updateui.exe > > > > are they the malware software? > > > > > > TCP127.0.0.1:1663 127.0.0.1:28091 > ESTABLISHED 9900 > > TCP127.0.0.1:7496 0.0.0.0:0 > LISTENING 7496 > > TCP127.0.0.1:270150.0.0.0:0 > LISTENING 9968 > > TCP127.0.0.1:280910.0.0.0:0 > LISTENING 9532 > > TCP127.0.0.1:28091127.0.0.1:1663 > ESTABLISHED 9532 > > TCP127.0.0.1:432270.0.0.0:0 > LISTENING 3772 > > TCP127.0.0.1:50.0.0.0:0 > LISTENING 9532 > > TCP192.168.1.102:1128 210.176.156.35:443 > FIN_WAIT_2 5124 > > TCP192.168.1.102:1509 64.233.188.102:443 > ESTABLISHED 6700 > > TCP192.168.1.102:1510 216.58.203.46:443 > ESTABLISHED 6700 > > TCP192.168.1.102:1511 216.58.203.46:443 > ESTABLISHED 6700 > > TCP192.168.1.102:1512 216.58.200.5:443 > ESTABLISHED 6700 > > TCP192.168.1.102:1513 172.217.26.195:443 > ESTABLISHED 6700 > > TCP192.168.1.102:1514 172.217.26.195:443 > CLOSE_WAIT 6700 > > TCP192.168.1.102:1898 111.221.29.156:443 > ESTABLISHED 1544 > > This question is about systems administration and has nothing > to do with Python. > > To figure out what each connection represents, you'll have to > figure out what programs are on the two ends. (In the case of > listening sockets, figure out which program is listening.) > Then research what's actually being done by those programs. A > simple dump like this is not going to tell you much about > whether it's malware. > > ChrisA You can also look up the IP addresses with a DNS lookup tool that aren't your machine (127.0.0.1 and 192.168.1.102). This may be helpful if you recognize who they are, or you can google the IP addresses and/or their owners. If they're malware, Google will have lots of pages on them. This looks like a readout from Essential Net Tools running in Express mode. If you select Addvanced mode, ENT will tell you the process name and lots of other good stuff for each entry, plus ENT is a full network toolbox and you won't need Google. Deborah -- https://mail.python.org/mailman/listinfo/python-list
RE: syntax error in first-time user script
john polo wrote, on March 25, 2017 2:45 PM > > I had a misconception of how the Python interpreter works. If > I have a > script, call it example.py, in order to run it, I shouldn't be in the > interpreter? In other words, I should be at the Windows > command prompt, > for example > > C:/test> python example.py > > and not > > >>> python example.py > > ? > > So, if I am already on >>> and have a problem with a script > and need to > edit it and want to run the script again, how do I do that? Do I exit > the interpreter and start it again? Or is there a different > way to run > the script once the interpreter is active and I am at >>> ? > > Cheers, > John In IDLE, to run a script, open the .py file from the file menu and click Run Module from the Run menu. You can easily edit the .py file while it's open in the editor -- https://mail.python.org/mailman/listinfo/python-list
