python software foundation

[Jithesh Thirumaran]

Have you uninstall the site package of the python version 3.7.2
please reply me immediately
Thank you,
(T.Jithesh)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python software foundation

[Souvik Dutta]

No.

On Sat, Jul 11, 2020, 4:04 PM Jithesh Thirumaran 
wrote:

> Have you uninstall the site package of the python version 3.7.2
> please reply me immediately
> Thank you,
> (T.Jithesh)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Unable to login | fbchat.Client

[Shivam Dutt Sharma]

Dear All,


I am facing an error while trying to log-in to fbchat.Client. This is
obviously despite me entering absolutely correct ID & P/W. It could be
because of any latest update in the package, or a user_agent / session
(cookies) issue too.

Prima-facie, if you think a few adjustments need to be made in the
client or state file/s, please let me know, else I shall share the
complete code link for your perusal.


Below's the error message. I will be highly grateful, if I can get an
idea of where am I going wrong?


*Logging in xx.x.xx...
Attempt #1 failed, retrying
Traceback (most recent call last):
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_client.py",
line 209, in login
user_agent=user_agent,
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 149, in login
return cls.from_session(session=session)
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 186, in from_session
fb_dtsg = FB_DTSG_REGEX.search(r.text).group(1)
AttributeError: 'NoneType' object has no attribute 'group'*


*Best,*

*Shivam Dutt Sharma*

*LinkedIn : shivam-dutt-sharma-020456149
*

*PGP in Machine Learning | NIT WarangalFundraising Volunteer @ The AIM
Foundation*

*PCEP @ PythonInstitute*






-- Forwarded message -
From: Shivam Dutt Sharma 
Date: Sun, Jul 5, 2020 at 8:38 AM
Subject: Unable to login | fbchat.Client
To: 


Dear All,


I am facing an error while trying to log-in to fbchat.Client. This is
obviously despite me entering absolutely correct ID & P/W. It could be
because of any latest update in the package, or a user_agent / session
(cookies) issue too.

Prima-facie, if you think a few adjustments need to be made in the
client or state file/s, please let me know, else I shall share the
complete code link for your perusal.


Below's the error message. I will be highly grateful, if I can get an
idea of where am I going wrong?


*Logging in xx.x.xx...
Attempt #1 failed, retrying
Traceback (most recent call last):
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_client.py",
line 209, in login
user_agent=user_agent,
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 149, in login
return cls.from_session(session=session)
  File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 186, in from_session
fb_dtsg = FB_DTSG_REGEX.search(r.text).group(1)
AttributeError: 'NoneType' object has no attribute 'group'*


*Best,*

*Shivam Dutt Sharma*

*LinkedIn : shivam-dutt-sharma-020456149
*

*PGP in Machine Learning | NIT WarangalFundraising Volunteer @ The AIM
Foundation*

*PCEP @ PythonInstitute*


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

Need a Dynamic vlookup using python

[narenchunduri]

Any suggestions please
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unable to login | fbchat.Client

[2QdxY4RzWzUUiLuE]

On 2020-07-11 at 12:56:22 +0530,
Shivam Dutt Sharma  wrote:

> *Logging in xx.x.xx...
> Attempt #1 failed, retrying
> Traceback (most recent call last):
>   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_client.py",
> line 209, in login
> user_agent=user_agent,
>   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
> line 149, in login
> return cls.from_session(session=session)
>   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
> line 186, in from_session
> fb_dtsg = FB_DTSG_REGEX.search(r.text).group(1)
> AttributeError: 'NoneType' object has no attribute 'group'*

I don't know anything about fbchat, but it looks like
FB_DTSG_REGEX.search is returning None (indicating that the search
failed), which doesn't have an attribute named "group."

I would suggest breaking up fb_dtsg =
FB_DTSG_REGEX.search(r.text).group(1) into multiple statements and
testing the result of the search before assuming that there's a group
attribute:

xxx = FB_DTSG_REGEX.search(r.text)
if xxx:
fb_dtsg = xxx.group(1)
else:
print("the search failed, now what?")
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unable to login | fbchat.Client

[MRAB]

On 2020-07-11 08:26, Shivam Dutt Sharma wrote:

Dear All,


I am facing an error while trying to log-in to fbchat.Client. This is
obviously despite me entering absolutely correct ID & P/W. It could be
because of any latest update in the package, or a user_agent / session
(cookies) issue too.

Prima-facie, if you think a few adjustments need to be made in the
client or state file/s, please let me know, else I shall share the
complete code link for your perusal.


Below's the error message. I will be highly grateful, if I can get an
idea of where am I going wrong?


*Logging in xx.x.xx...
Attempt #1 failed, retrying
Traceback (most recent call last):
   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_client.py",
line 209, in login
 user_agent=user_agent,
   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 149, in login
 return cls.from_session(session=session)
   File "C:\Users\my\Anaconda3\lib\site-packages\fbchat\_state.py",
line 186, in from_session
 fb_dtsg = FB_DTSG_REGEX.search(r.text).group(1)
AttributeError: 'NoneType' object has no attribute 'group'*



[snip]
You should look at the fbchat project itself.

This looks like the same problem:

https://github.com/carpedm20/fbchat/issues/517
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Peter J. Holzer]

On 2020-07-11 09:54:33 +1200, dn via Python-list wrote:
> Questions:
> 
> Is the idea of limiting the number of parameters passed across an interface
> a real concern or somewhat an affectation?
> 
> Is three, five, seven, ... a valid limit (or warning-signal)?
> 
> Do you have a personal or corporate style or 'standard' to limit parameter
> lists to seven parameters, or some other number?
> 
> Given that Python enables labeled arguments ("keyword arguments"), does the
> concern really only apply to 'us' in terms of numbers of "positional
> arguments"?

Keyword arguments greatly ameliorate the problems I have with long
parameter lists. While I think that calling a function with 7 positional
parameters is pretty much unreadable, with 7 named parameters (or maybe
2 positional and 5 named parameters) it doesn't bother me much. The
definition of the function might have even more parameters, as long as
most of them are optional and have sensible defaults (subprocess.Popen
with 20 parameters (if I counted correctly) is pushing it, though).


> Why not simply create and pass a collection (to suit the 'standards
> committee') and be done. What's the big deal, don't have time to waste,
> bureaucracy (!)...
> 
> What about the similar Q+D solution using a class?

That's what I often do. The main reason is that often a lot of those
parameters are repetitive. So instead of passing the same 7 parameters
to every function, I create a "Context" or "Job" class with those 7
fields which I then pass to each function. So it not just looks tidier,
it also reduces the risk of inconsistencies.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


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

Re: Need a Dynamic vlookup using python

[DL Neil via Python-list]

On 11/07/20 8:34 PM, narenchund...@gmail.com wrote:

Any suggestions please



Clarify the requirements, rather than starting with a 'solution'.
Communicate the constraints, eg what is already in-place.

"vlookup" has particular meaning in worksheet/spreadsheet packages. Is 
that what you are using? If so, with which Python interfacing package?


Are you using one of Python's math/stats packages to hold and analyse 
the data?


Remember please that all-here are volunteers, and will find it easier to 
help you if you (first) help us to understand the problem and your 
intentions...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[DL Neil via Python-list]

On 12/07/20 8:13 AM, Peter J. Holzer wrote:

On 2020-07-11 09:54:33 +1200, dn via Python-list wrote:

Questions:

Is the idea of limiting the number of parameters passed across an interface
a real concern or somewhat an affectation?

Is three, five, seven, ... a valid limit (or warning-signal)?

Do you have a personal or corporate style or 'standard' to limit parameter
lists to seven parameters, or some other number?

Given that Python enables labeled arguments ("keyword arguments"), does the
concern really only apply to 'us' in terms of numbers of "positional
arguments"?


Keyword arguments greatly ameliorate the problems I have with long
parameter lists. While I think that calling a function with 7 positional
parameters is pretty much unreadable, with 7 named parameters (or maybe
2 positional and 5 named parameters) it doesn't bother me much. The
definition of the function might have even more parameters, as long as
most of them are optional and have sensible defaults (subprocess.Popen
with 20 parameters (if I counted correctly) is pushing it, though).


Do you think, then, that the maxima should be applied to the number of 
arguments that will appear in the 'expected usage' of the routine? (cf 
the def's parameter-list) After all, calling Popen would rarely require 
all-20 arguments be stated, given the acceptability of the defaults and 
the irrelevance of many 'special cases'.


Alternately/additionally, do you feel that the power and readability of 
Python's keyword-arguments + default-values, requires a modification of 
the advice to only limit the number of positional-arguments?


Another discussion-point (which may be difficult because 'the answer' 
may vary according to implementation-requirements): rather than one 
do-it-all 'Swiss Army Knife' of a routine with dozens of parameters, 
might it be better-practice to code a number of methods/functions to 
take care of the special-cases, with a single 'core function' to 
carry-out the basic operations-required? (in a class environment: 
sub-classes maybe)




Why not simply create and pass a collection (to suit the 'standards
committee') and be done. What's the big deal, don't have time to waste,
bureaucracy (!)...

What about the similar Q+D solution using a class?


That's what I often do. The main reason is that often a lot of those
parameters are repetitive. So instead of passing the same 7 parameters
to every function, I create a "Context" or "Job" class with those 7
fields which I then pass to each function. So it not just looks tidier,
it also reduces the risk of inconsistencies.


+1
Good thinking: promotes (indeed, dictates) consistency of interface!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Christman, Roger Graydon]

I'll preface this by saying I am a programming instructor
who still teaches from the ivory tower, so may not necessarily
reflect actual practice in industry.

But I have a very simple rule of thumb for limiting parameters:
One should be able to summarize what a function does in one or two
sentences,  e.g. computes the volume of a cone, or print address labels.
To fully understand the details of the task would certainly involve
listing the parameters, but I would generally expect that a practical
function would naturally put a cap on how much data is provided.
If you need to include more than 7 parameters to describe what
it is you want to do, you are probably doing more than one thing,
or doing something unnecessarily complicated.

I'll take your example with the address, and assume I want to
print a mailing label.I could certainly see you needing to print:
first name, middle initial, last name, house number, street name,
apartment number, town, state, country, zip code, (and maybe more),
and listing all of those individually would produce a very long list.

But these values really are not all that independent of each other.
A person's name can be viewed as a single value that happens to
have multiple parts (collect that into a tuple or class).   Similarly,
a street address is a single object with multiple parts.   These can
easily be delivered as complete objects for a short parameter list.

That does not necessarily mean that the function needs to know
the particular representation or form of that data.   Let those be
objects with getter methods for the data you wish, and have the
function document what methods it will attempt to call.   Then
any class that provides the expected methods would be suitable.

That would also greatly simplify some other features for the problem.
For example, "first name" "last name" really does not mean the same
thing as "individual name" "family name", when some countries
list the family name first.   So it might be better to have a name
object include a "full name" method for the print-mailing-address
function to call instead of giving it access to component parts.

TL;DR:  I expect each parameter to a function to be independent
or orthogonal to the others.   Values that are closely related to
each other can probably be encapsulated into a collection or object.
If you still end up with a large number of independent parameters,
I would question the simplicity of your function's intent.

Roger Christman
Pennsylvania State University
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[DL Neil via Python-list]

On 12/07/20 9:46 AM, Christman, Roger Graydon wrote:

I'll preface this by saying I am a programming instructor
who still teaches from the ivory tower, so may not necessarily
reflect actual practice in industry.


...in which case I will preface my response by saying that one of the 
virtues of this Discussion List is that we enjoy a wide range of 
membership. It is not limited or even focussed on 'professionals, so 
'ivory tower' members have no less to offer. Similarly, insight from 
ardent hobbyists who (effectively) pay to use Python!



PS there is a Python-Tutor list catering to both trainers and trainees 
which may be of interest and/or a resource for your students. Details at 
https://mail.python.org/mailman/listinfo



Thank you for your considered response!



But I have a very simple rule of thumb for limiting parameters:
One should be able to summarize what a function does in one or two
sentences,  e.g. computes the volume of a cone, or print address labels.
To fully understand the details of the task would certainly involve
listing the parameters, but I would generally expect that a practical
function would naturally put a cap on how much data is provided.
If you need to include more than 7 parameters to describe what
it is you want to do, you are probably doing more than one thing,
or doing something unnecessarily complicated.


+1
(see also @Peter's example of ~20 parameters, and in PSL code, no less!)



I'll take your example with the address, and assume I want to
print a mailing label.I could certainly see you needing to print:
first name, middle initial, last name, house number, street name,
apartment number, town, state, country, zip code, (and maybe more),
and listing all of those individually would produce a very long list.

But these values really are not all that independent of each other.
A person's name can be viewed as a single value that happens to
have multiple parts (collect that into a tuple or class).   Similarly,
a street address is a single object with multiple parts.   These can
easily be delivered as complete objects for a short parameter list.


A good summary.

Is there a counter-argument, that because the tuple or class is an 
encapsulation, its contents have to be taken on-trust - the component 
list is not as explicit as: street, number, town, city. Are we a 
particularly 'trusting' bunch? (particularly those who have been 
'bitten' by assumptions in the past...)




That does not necessarily mean that the function needs to know
the particular representation or form of that data.   Let those be
objects with getter methods for the data you wish, and have the
function document what methods it will attempt to call.   Then
any class that provides the expected methods would be suitable.


+1

Here, the proposal is not to pass an object per-se, but to pass a 
function/method ("getter method") which will deliver the requisite 
data-items?


So, might we then find that our mailing-label routine includes something 
like (copy-pasting is NOT proper Python!):


def mail_label( getter ):
...
( first name, middle initial, last name, house number, street name,
apartment number, town, state, country, zip code ) = getter()

In which case, have we not moved the "very long list" from the function 
def to a later line within the routine - and how is this in some way 
'better'?




That would also greatly simplify some other features for the problem.
For example, "first name" "last name" really does not mean the same
thing as "individual name" "family name", when some countries
list the family name first.   So it might be better to have a name
object include a "full name" method for the print-mailing-address
function to call instead of giving it access to component parts.


+1
As mentioned, keep all the 'stuff' related to person/address in one 
place, rather than expecting mail_label() to know the attributes of the 
class! ('stuff' meaning the data-access methods as well as the 
data-attributes themselves)




TL;DR:  I expect each parameter to a function to be independent
or orthogonal to the others.   Values that are closely related to
each other can probably be encapsulated into a collection or object.
If you still end up with a large number of independent parameters,
I would question the simplicity of your function's intent.


Well said! Zen of Python (includes):
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list