Re: Extract lines from file, add to new files
On 2024-01-13 at 11:34:29 +0100, Left Right wrote: > > The Python term, at least colloquially, is "tuple unpacking." That quote is from me. Please do preserve attributions. > Well, why use colloquialism if there's a language specification? Also, > there weren't any tuples used in my example, at least not explicitly > (i could've been a tuple, but that wasn't specified). According to the language specification,⁰ it's a "target list," and there can be more than one target in that list. The unpacking isn't really called anything, it's just the way Python assignment works, all the way back to its earliest stages.¹ ⁰ https://docs.python.org/3/reference/simple_stmts.html#assignment-statements, ¹ https://docs.python.org/release/1.4/ref/ref6.html#HDR2 -- https://mail.python.org/mailman/listinfo/python-list
best tool to extract domain hierarchy from a dimension in an OLAP dataset (csv)
Hi all, I have a csv OLAP dataset that I want to extract the domain hierarchies from each of its dimensions. Anybody could recommend a Python tool that could manage this properly? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 13/01/24 1:45 pm, Left Right wrote: I use the term "destructuring" in the same way Hyperspec uses it. It's not a Python term. I don't know what you call the same thing in Python. I'm not sure what you understand from it. I thought you meant what is usually called "unpacking" in Python. I don't know anything about Hyperspec, so I don't know what it means there. The fact that i was being printed inside the loop made me think that some deeper level of surprise was being intended, such as the value of i somehow getting changed by the assignment. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 13/01/24 3:14 pm, Chris Angelico wrote:
On Sat, 13 Jan 2024 at 13:11, Left Right via Python-list
wrote:
Very few
languages allow arbitrary complex expressions in the same place they
allow variable introduction.
What do you mean by this? Most languages I've worked with allow
variables to be initialized with arbitrary expressions, and a lot of
languages allow narrowly-scoped variables.
I think he means that in some languages the for-loop target serves as
the declaration of a new variable, and as such has to be a bare name.
Python isn't like that -- the target of a for-statement is treated
exactly the same way as the lhs of an assignment. It's not scoped to the
loop.
BTW, the equivalent thing is valid in C too, so anyone familiar with C
is unlikely to be surprised by this either.
#include
int x[10];
int i;
int main() {
i = 5;
for (x[i] = 0; x[i] < 10; x[i]++)
printf("%d\n", x[i]);
}
Output:
0
1
2
3
4
5
6
7
8
9
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
Am Fri, Jan 12, 2024 at 02:23:43PM +0100 schrieb Antoon Pardon via Python-list: > > queries:list[dict[str, str | list | dict[str, Any]]]=None, > > > >into > > > > "List[Dict[str, Union[str, List[Any], Dict[str, Any" > > > >seems accurate. I just don't understand why list[dict[str, > >str]] should not pass that construct. > > Sorry for the late reaction ne'er mind ya > I was wondering if > your type hint for queries shouldn't be the following. > > queries:list[dict[str,str]|dict[str,list]|dict[str,dict[str, dict[str, Ant]]] > > My impression at this moment is that you are write something like: dict[str, > str | int] as > as shorthand for dict[str, str] | dict[str, int]. I do. > But those two are different types. A-ha ! In what way ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
Am Sat, Jan 13, 2024 at 09:20:00PM +0100 schrieb Karsten Hilbert via
Python-list:
> > I was wondering if
> > your type hint for queries shouldn't be the following.
> >
> > queries:list[dict[str,str]|dict[str,list]|dict[str,dict[str, dict[str,
> > Ant]]]
Wait, not really. Let me give an example. Here's three times
the same query (as far as PostgreSQL is concerned, after
having been passed through psycopg2):
queries = [
{
'SQL': 'SELECT 1'
},
{
'SQL': 'SELECT %s',
'args': [1]
},
{
'SQL': 'SELECT %(value)s',
'args': {'value': 1}
}
]
The value for key "SQL" will always be str-like.
The value for "args" can be a list or a dict itself.
If "args" is a dict it will be of type [str, Any].
That's what I am trying to tell mypy.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 12/01/24 08:53, Rich Shepard via Python-list wrote:
On Thu, 11 Jan 2024, Piergiorgio Sartor via Python-list wrote:
Why not to use bash script for all?
Piergiorgio,
That's certainly a possibility, and may well be better than python for this
task.
(sitting in a meeting with little to occupy my mind, whilst tidying
email-InBox came back to this conversation)
In the bare-description of the task, I might agree to sticking with
BASH. The OP did say that the output from this will become input to a
sed/mailx task!
(we trust, does not involve spamming innocent folk)
However, that task could also be accomplished in Python. So, unless
there is an existing script (perhaps) quite why one would choose to do
half in Python and half in BASH (or...) is a question.
Because this is a Python forum, do the whole thing in one mode - our mode!
Previous suggestions involved identifying a line by its content.
Could use a neat state-transition solution.
However, there is no need to consider the input-data as lines because of
the concept of "white-space", well-utilised by some of Python's built-in
string-functions. See code-sample, below.
As mentioned before, the idea of splitting the one file (data-items
related by serial-progression) and creating two quite-separate
data-constructs (in this case: one holding the person's name in one file
and the other the person's email-address in another) which are related
'across', ie line-by-line, is an architectural error?horror. Such would
be hard to maintain, and over-time impossible to guarantee integrity.
Assuming this is not a one-off exercise, see elsewhere for advice to
store the captured data in some more-useful format, eg JSON, CSV, or
even put into a MongoDB or RDBMS.
** code
""" PythonExperiments:rich.py
Demonstrate string extraction.
"""
__author__ = "dn, IT&T Consultant"
__python__ = "3.12"
__created__ = "PyCharm, 14 Jan 2024"
__copyright__ = "Copyright © 2024~"
__license__ = "GNU General Public License v3.0"
# PSL
import more_itertools as it
DATA_FILE = "rich_data_file"
READ_ONLY = "r"
AS_PAIRS = 2
STRICT_PAIRING = True
if __name__ == "__main__":
print("\nCommencing execution\n")
with open( DATA_FILE, READ_ONLY, ) as df:
data = df.read()
data_as_list = data.split()
paired_data = it.chunked( data_as_list, AS_PAIRS, STRICT_PAIRING, )
for name, email_address in paired_data:
# replace this with email-function
# and/or with storage-function
print( name, email_address, )
print("\nTerminating")
** sample output
Calvin [email protected]
Hobbs [email protected]
...
**
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Mtg: Object-Oriented VacExcHndlrs (UTC+13)
Let's meet on Wednesday (17Jan, 1600 NZDT (UTC+13), wearing a head-set) to talk about Object-Oriented everything. Is O-O worthwhile, or does is it just a load of guys running around and getting no-where? NB this is not a formal PUG-meeting. It's part of the "Vacation Exception Handlers" series (https://danceswithmice.info/Python/2024/VacExcHndlrs.html) - virtual-gatherings for folk left-behind to keep the wheels turning, whilst everyone else swans-off sunning themselves... (non-Kiwis please remember: it's not just school vacation, but summer-time down-under. Wish you were here?) Café-style approach, so there will be no formal presentation. All welcome. No presumption of knowledge/skill. This gathering is for everyone, from Beginner to Python-Master. Is Python an Object-Oriented language? Why does Python use (what appear to be) procedural constructs for so many of its core functions, eg len(a_list) rather than a_list.length() and sqrt(a_number) rather than a_number.sqrt()? Why do pythonista say "everything in Python is an object"? Is it faster to write in an OOP-style and/or does OOP-code run faster? If not, why bother? - insert your question here: What do you want to know? What has been bothering you about OOP (or O-O in Python) that you'd like to settle? To join us (we don't bite!), please RSVP at https://www.meetup.com/nzpug-auckland/events/298536620/ -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 13/01/24 00:11, Left Right via Python-list wrote: To people discussing BNF: The grammar language Python uses is *very* far from BNF. It's more similar to PEG, but even then it's still quite far. Python's grammar is just its own thing, which makes it harder to read, if you are already familiar with other more popular formats. Second time to ameliorate wording-dispute in this thread! The original phrase was: "[modified] BNF". Some of us have worked with various forms and evolutions of BNF since back in the days of COBOL-60 proposals, and know it when we see it! From the 'book of words': <>> https://docs.python.org/3/reference/introduction.html#notation Yes it is hard to read - and even harder to learn-from; which is why @Chris gave advice about preferring tutorials/text. Just because there are other (more popular?) formats, doesn't make the one used here 'wrong'. In the same way that Python code differs from 'the same' in other languages. Putting it another way: if what Python is doing is wrong in your opinion, you are in the wrong place (for you). That is not to say that Python has everything 'right'. One of my own bug-bears is very similar - that the string formatting 'mini-language' (https://docs.python.org/3/library/string.html#formatspec) does not follow the same rules about white-space as everything covered by the PEG Parser. BTW the PEG Parser is relatively new to Python. IIRC there was comment at the time of its first application, that some 'other' areas of Python might take a while to be converted-over. I've also found bugs in Python parser before, so had this turned out Sorry, didn't recognise your email-handle - not that I'm a Python Core-Dev, and pretty much ignore the "Ideas" list these days. Must have missed your previous contributions... to be a real issue, this wouldn't have been the first time. There are plenty of weird corners in Python grammar that allow unexpected programs to parse (and sometimes even run!), and these are very often connected to assignments, because, in general, assignments in Python are very elaborate and hard to describe / conceptualize about. The most popular example I've even seen used in coding interviews (which I think is a silly gimmick, but that's kind of the whole point of a lot of these interviews...) is: x = [...] for x[i] in x: print(i) Which is not an assignment by itself, but the "weirdness" results from the loop syntax sharing definitions with the "destructuring bind" style of assignment (i.e. where the left-hand side can be an arbitrary complex expression). You're right. (also about stupid 'interviewing' ideas) If someone asked me this, I'd respond by asking if that was the standard of code they work towards - and depending upon that answer would either walk-out or refer the matter to a more senior manager! In Python, everything is an object. As long as the LHS is a legal-object which makes sense for the situation, it can be used. Also, an identifier (whether x, i, or x[ i ]) should not only be considered to be its own object, but is best regarded as a pointer to some value. This is how we can have an 'immutable' tuple 'containing' a mutable list (for example) - such that elements of that list may be changed, despite being 'part of' an immutable construct! Programs are read by people. If something is a "weirdness", then chances-are it won't survive a CodeReview/a professional team's expected-standard. Not limited to Python-code! I was surprised, for example, to learn that "as" in "with_stmt" isn't shared with "as" in "except_block" (so, from the grammar perspective, these are two different keywords), and that asterisk in "except_block" isn't shared with "star_target" (also weird, since you'd think these should be the same thing). In general, and by and large, if you look at Python's grammar there are many "weird" choices that it makes to describe the language which seem counterintuitive to the programmer who tries to learn the language from examples (i.e. context-depending meaning of parenthesis, of asterisk, of period etc.) Having been exposed to this, you'd start to expect that some of this weirdness will eventually result in bugs, or at least in unexpected behavior. You're right. It is potentially confusing when the same word/symbol is used in different contexts. I've heard similar questions from learners, but not had anyone trying to mis-use something extrapolating from how the 'same' is used elsewhere. YMMV! It's the context part that's important to remember. If someone calls you "mate", that has different connotations depending upon whether you're friends, you're on a Navy ship, or in a more intimate situation - indeed there are some cultures in which the word "mate" is not used to mean 'friend' at all. Which is (more) right? Which wrong? Perhaps you're aiming for, or even used to, a more
Re: Extract lines from file, add to new files
On Sun, 14 Jan 2024 at 14:43, dn via Python-list wrote: > Similarly, whilst we could write: > > a, b, c = 1, 2, 3 > I would only do this when it aligns particularly well with the algorithm being implemented. For example, you could start a Fibonacci evaluator with "a, b = 0, 1". Otherwise, there's not all that much reason to unpack three constants in this way. (Though I am much more likely to use multiple initialization to set a bunch of things to the SAME value, lilke "a = b = c = 0".) -- https://mail.python.org/mailman/listinfo/python-list
