Re: TkInter Scrolled Listbox class?
This is what I created ScrollableContainers for. Its usage deviates a bit from standard Tkinter practices in that you add widgets to the frame attribute of a ScrollableFrameTk instance. [1]twitter.abaf4b19.webp [2]ScrollableContainers pypi.org For your use case, you could populate your list box and then put it inside that frame. I’ve not tested this scenario, so I’d appreciate feedback! Thanks. On 4 Nov 2024, at 21:28, Ulrich Goebel via Python-list wrote: Hi, I would like to build a class ScrolledListbox, which can be packed somewhere in ttk.Frames. What I did is to build not really a scrolled Listbox but a Frame containing a Listbox and a Scrollbar: class FrameScrolledListbox(ttk.Frame): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) # # build Listbox and Scrollbar self.Listbox = tk.Listbox(self) self.Scrollbar = ttk.Scrollbar(self) # # configure these two self.Listbox.config(yscrollcommand=self.Scrollbar.set) self.Scrollbar.config(command=self.Listbox.yview) # # pack them in Frame self.Listbox.pack(side=tk.LEFT, fill=tk.BOTH) self.Scrollbar.pack(side=tk.RIGHT, fill=tk.BOTH) That works, so instances of FrameScrolledListbox can be packed and the tk.Listbox itself is accessible via an attribute: frmScrolledListbox = FrameScrolledListbox(main) frmScrolledListbox.Listbox.config(...) But it would be a bit nicer to get a class like class ScrolledListbox(tk.Listbox): ... So it would be used that way: scrolledListbox = ScrolledListbox(main) scrolledListbox.config(...) Is that possible? The problem which I can't handle is to handle the Frame which seems to be needed to place the Scrollbar somewhere. Best regards Ulrich -- Ulrich Goebel -- https://mail.python.org/mailman/listinfo/python-list References Visible links 1. https://pypi.org/project/ScrollableContainers/ 2. https://pypi.org/project/ScrollableContainers/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing UTF-8 mail to terminal
On 2024-11-04 13:02:21 +0100, Loris Bennett via Python-list wrote:
> "Loris Bennett" writes:
> > "Loris Bennett" writes:
> >> Cameron Simpson writes:
> >>> On 01Nov2024 10:10, Loris Bennett wrote:
> as expected. The non-UTF-8 text occurs when I do
>
> mail = EmailMessage()
> mail.set_content(body, cte="quoted-printable")
> ...
>
> if args.verbose:
> print(mail)
>
> which is presumably also correct.
>
> The question is: What conversion is necessary in order to print the
> EmailMessage object to the terminal, such that the quoted-printable
> parts are turned (back) into UTF-8?
[...]
> OK, so I can do:
>
> ##
> if args.verbose:
> for k in mail.keys():
> print(f"{k}: {mail.get(k)}")
> print('')
> print(mail.get_content())
> ##
>
> prints what I want and is not wildly clunky, but I am a little surprised
> that I can't get a string representation of the whole email in one go.
Mails can contain lots of stuff, so there is in general no suitable
human readable string representation of a whole email. You have to go
through it part by part and decide what you want to do with each. For
example, if you have a multipart/alternative with a text/plain and a
text/html part what should the "string representation" be? For some uses
the text/plain part might be sufficient. For some you might want the
HTML part or some rendering of it. Or what would you do with an image?
Omit it completely? Just use the filename (if any)? Try to convert it to
ASCII-Art? Use an AI to describe it?
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
Two python issues
L.S.,
Python seem to suffer from a few poor design decisions regarding strings
and lists that affect the elegance of the language.
(a) An error-prone "feature" is returning -1 if a substring is not found
by "find", since -1 currently refers to the last item. An example:
>>> s = 'qwertyuiop'
>>> s[s.find('r')]
'r'
>>> s[s.find('p')]
'p'
>>> s[s.find('a')]
'p'
>>>
If "find" is unsuccessful, an error message is the only clean option.
Moreover, using index -1 for the last item is a bad choice: it should be
len(s) - 1 (no laziness!).
Negative indices should be reserved for elements preceding the element
with index 0 (currently not implemented, but a must for orthogonal
design supporting general sequences).
(b) When using assignment for slices, only lists with the same length as
the slice should be acceptable, otherwise an error should be given.
Anything that re-indexes items not covered by the slice is against the
essential idea of assignment. For changes that imply re-indexing (e.g.,
inserting a list longer than the slice), Python offers cleaner solutions.
Comments are welcome.
With best regards,
Raymond
--
https://mail.python.org/mailman/listinfo/python-list
Re: Printing UTF-8 mail to terminal
On 04Nov2024 13:02, Loris Bennett wrote:
OK, so I can do:
##
if args.verbose:
for k in mail.keys():
print(f"{k}: {mail.get(k)}")
print('')
print(mail.get_content())
##
prints what I want and is not wildly clunky, but I am a little surprised
that I can't get a string representation of the whole email in one go.
A string representation of the whole message needs to be correctly
encoded so that its components can be identified mechanically. So it
needs to be a syntacticly valid RFC5322 message. Thus the encoding.
As an example (slightly contrived) of why this is important, multipart
messages are delimited with distinct lines, and their content may not
present such a line (even f it's in the "raw" original data).
So printing a whole message transcribes it in the encoded form so that
it can be decoded mechanically. And conservativly, this is usually an
ASCII compatibly encoding so that it can traverse various systems
undamaged. This means the text requiring UTF8 encoding get further
encoded as quoted printable to avoid ambiguity about the meaning of
bytes/octets which have their high bit set.
BTW, doesn't this:
for k in mail.keys():
print(f"{k}: {mail.get(k)}")
print the quoted printable (i.e. not decoded) form of subject lines?
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Two python issues
>
> (a) An error-prone "feature" is returning -1 if a substring is not found
> by "find", since -1 currently refers to the last item. An example:
>
> >>> s = 'qwertyuiop'
> >>> s[s.find('r')]
> 'r'
> >>> s[s.find('p')]
> 'p'
> >>> s[s.find('a')]
> 'p'
> >>>
>
> If "find" is unsuccessful, an error message is the only clean option.
> Moreover, using index -1 for the last item is a bad choice: it should be
> len(s) - 1 (no laziness!).
>
I'm not sure if this answers your objection but the note in the
documentation (https://docs.python.org/3/library/stdtypes.html#str.find)
says:
The find() method should be used only if you need to know the position of
sub.
I think the use case above is a little bit different.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Two python issues
On 6/11/24 10:08, Jason Friedman via Python-list wrote:
(a) An error-prone "feature" is returning -1 if a substring is not found
by "find", since -1 currently refers to the last item. An example:
>>> s = 'qwertyuiop'
>>> s[s.find('r')]
'r'
>>> s[s.find('p')]
'p'
>>> s[s.find('a')]
'p'
>>>
If "find" is unsuccessful, an error message is the only clean option.
Moreover, using index -1 for the last item is a bad choice: it should be
len(s) - 1 (no laziness!).
I'm not sure if this answers your objection but the note in the
documentation (https://docs.python.org/3/library/stdtypes.html#str.find)
says:
The find() method should be used only if you need to know the position of
sub.
I think the use case above is a little bit different.
Not really, there are two questions:
1. is x in sequence (or in this case "not in")
2. where is x within sequence (find())
There are situations where one might be used, similarly where the other
will be used, and still more where both apply.
That said, and with @Cameron's observation, the idea that a function's
return-value (appears to) performs two functionalities is regarded as a
'code-smell' in today's world - either it indicates "found" or it
indicates "where found" (see also various APIs which return both a
boolean: success/fail, and a value: None/valid-info).
The problem with the third scenario being that purity suggests we should
use both (1) and (2) which seems like duplication - and is certainly
going to take more CPU time.
(will such be noticeable in your use-case?)
Backward-compatibility... ('nuff said!)
With reference to the OP content about slicing:
- Python's memory-addressing is different from many other languages.
Thus, requires study before comparison/criticism
- there are major differences in what can be accomplished with mutable
and immutable objects
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Two python issues
On 05Nov2024 15:48, Raymond Boute wrote: Python seem to suffer from a few poor design decisions regarding strings and lists that affect the elegance of the language. (a) An error-prone "feature" is returning -1 if a substring is not found by "find", since -1 currently refers to the last item. `find` is a pretty old API interface. It is what it is. It may obtain some of its design choices from C style calls where returning -1 for failure was a common idiom. If "find" is unsuccessful, an error message is the only clean option. This is not true. Often we want to look for something, and act one way or another depending on whether it is found. I've got plenty of loops and other tests which more or less go "run until this is not found". It is not an error, it is just a circumstance to accomodate. Moreover, using index -1 for the last item is a bad choice: it should be len(s) - 1 (no laziness!). Negative indices should be reserved for elements preceding the element with index 0 (currently not implemented, but a must for orthogonal design supporting general sequences). It is _far_ too late to propose such a change. Plenty of us are quite hapoy with negative indices. We just view them as counting backwarss from the end of the string or sequence instead of forwards from the beginning. (b) When using assignment for slices, only lists with the same length as the slice should be acceptable, otherwise an error should be given. There are many many circumstances where we replace a subsequence with a different subsequence of different length. Outlawing such a thing would remove and extremely useful feature. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Specifying local dependency with Poetry
Hi, I have installed a package, 'first-package, built using Poetry and installed it as root in /usr/local. The package is on sys.path so root can successfully import it. I have now developed a second package which depends on 'first-package'. I would have expected that I could specify this dependency in pyproj.toml via [tool.poetry.dependencies] python = "^3.6" first-package = "^1.6.0" However, if I do that and then attempt to install the second package, I get the error Could not find a version that satisfies the requirement first-package<2.0.0,>=1.6.0 (from second-package==0.5.0) (from versions: ) No matching distribution found for first-package<2.0.0,>=1.6.0 (from second-package==0.5.0) How should I define the dependency? Cheers, Loris -- This signature is currently under constuction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Specifying local dependency with Poetry
On 6/11/24 4:13 am, Loris Bennett wrote: [tool.poetry.dependencies] python = "^3.6" first-package = "^1.6.0" Could not find a version that satisfies the requirement first-package<2.0.0,>=1.6.0 (from second-package==0.5.0) (from versions: ) No matching distribution found for first-package<2.0.0,>=1.6.0 (from second-package==0.5.0) What version number does first-package have? The caret in the specification "^1.6.0" restricts it to 1.x.x versions. If you don't want that restriction, use ">=" instead. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
