Re: Friday Finking: Limiting parameters
> On 12 Jul 2020, at 00:15, DL Neil via Python-list
> wrote:
>
>> 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'?
>
This is not the refactor that Roger's excellent rule-of-thumb implies.
Clearly moving the 20 positional args into a tuple is basically the same code,
and the same maintenance problem.
I'd expect to see something like this:
def mail_label( person, address ):
first_name = person.first_name
# or if you want a function interface
first_line_of_address = address.get_first_line()
Barry
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need a Dynamic vlookup using python
Sorry for not making it clear.
I tried below code
# import modules
from openpyxl import *
from openpyxl.styles import *
import webbrowser
import pandas
from openpyxl.worksheet.datavalidation import DataValidation
# Read all Excels into pandas dataframes
sowexcel = pandas.read_excel('Billing Roster - SOW.xlsx')
#Load the existing Resource Allocation Excel
wb = load_workbook('ACFC_Resource_Allocation.xlsx')
allocationsheet = wb.active
def load():
maxrow = allocationsheet.max_row
sow_list = sowexcel['SOW #'].tolist()
column_sow = ','.join(sow_list)
validator_sow = DataValidation(type='list',
formula1='"{}"'.format(column_sow), allow_blank=True)
allocationsheet.add_data_validation(validator_sow)
validator_sow.add('D2:D%s' %maxrow)
# save the file
wb.save('ACFC_Resource_Allocation.xlsx')
wb.close()
# Driver code
if __name__ == "__main__":
load()
file_open = webbrowser.open('ACFC_Resource_Allocation.xlsx')
In Billing Roster - SOW.xlsx I have new column data one is named as SOW and
other is named SOW Description (Match value for SOW).
And now when i open ACFC_Resource_Allocation.xlsx excel and for an example if
select a value in D2 (SOW) cell from the dropdown i should get a matching value
into E2 cell after the selection from dropdown.
I only have an idea than a vlookup from Excel like below should solve my case.
Not sure how to achieve in python.
=VLOOKUP(D2,'[Billing Roster - SOW.xlsx]SOW List'!$A$1:$B$14,1,FALSE)
Please let me know if am not still clear.
--
https://mail.python.org/mailman/listinfo/python-list
frozendict: an experiment
TL;DR: I tried to implement in CPython a frozendict here: https://github.com/Marco-Sulla/cpython Long explaining: What is a frozendict? It's an immutable dict. The type was proposed in the past but rejected: https://www.python.org/dev/peps/pep-0416/ So why did I try to implement it? IMO, apart the considerations in PEP 416, a frozendict can be useful: - as a faster base for types.MutableMappingProxy - as a substitute of namedtuple - as set values - as a faster dict. Indeed a frozendict does not need views. Keys, values and items can be cached and could be a subclass of frozendict that implements also the set API (values apart). A possible problem is that frozendict requires more memory, since the hash is cached. My implementation is very naif. I tried to do the simplest thing, without any speed improvement. I haven't added frozendict in marshal, and the pickle implementation is very raw... Furthermore, I didn't touch the AST parser at all, and I did not add any test for Python or the C API in the battery, but I've done my tests apart, in pytest. PS: I used for tests and benchmarks a little modified version of the tests for my Python implementation of frozendict: https://github.com/Marco-Sulla/python-frozendict/tree/master/test . The results are interesting. A CPython builtin frozendict is faster in every bench that immutables.Map, that uses the HAMT algorithm. and was proposed as alternative in PEP 603: https://www.python.org/dev/peps/pep-0603/ . Maybe because I implemented it in CPython and immutables.Map is a C extension. -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Limiting parameters
On 12/07/20 10:10 PM, Barry Scott wrote:
On 12 Jul 2020, at 00:15, DL Neil via Python-list
mailto:python-list@python.org>> wrote:
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'?
This is not the refactor that Roger's excellent rule-of-thumb implies.
Clearly moving the 20 positional args into a tuple is basically the same
code,
and the same maintenance problem.
Agreed!
I'd expect to see something like this:
def mail_label( person, address ):
first_name = person.first_name
# or if you want a function interface
first_line_of_address = address.get_first_line()
Does this idea move whole objects across the interface? (see earlier in
the thread) Taking a person class as subject and a mailing-label as the
function's object, aren't there two criticisms?
1 the function needs to know which attributes of the person and address
objects it wants to use, cf saying 'I need street, number, town, ...'*
2 "person" likely contains a load of data that is irrelevant to printing
a mail-label.
Why is this preferable to using a 'getter' method, or some other approach?
* your point (above) being that these need not be (say) a dozen data
elements, but could be just-enough data, and data-combinations which
identify the addressee and which represent the components of the address.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
