Re: Decoding bytes to text strings in Python 2

[Chris Angelico via Python-list]

On Mon, 24 Jun 2024 at 10:18, MRAB via Python-list
 wrote:
> Tkinter in recent versions of Python can handle astral characters, at
> least back to Python 3.8, the oldest I have on my Windows PC.

Good to know, thanks! I was hoping that would be the case, but I don't
have a Windows system to check on, so I didn't want to speak without
facts.

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

Re: Decoding bytes to text strings in Python 2

[MRAB via Python-list]

On 2024-06-24 00:30, Chris Angelico via Python-list wrote:

On Mon, 24 Jun 2024 at 08:20, Rayner Lucas via Python-list
 wrote:


In article ,
ros...@gmail.com says...
>
> If you switch to a Linux system, it should work correctly, and you'll
> be able to migrate the rest of the way onto Python 3. Once you achieve
> that, you'll be able to operate on Windows or Linux equivalently,
> since Python 3 solved this problem. At least, I *think* it will; my
> current system has a Python 2 installed, but doesn't have tkinter
> (because I never bothered to install it), and it's no longer available
> from the upstream Debian repos, so I only tested it in the console.
> But the decoding certainly worked.

Thank you for the idea of trying it on a Linux system. I did so, and my
example code generated the error:

_tkinter.TclError: character U+1f40d is above the range (U+-U+)
allowed by Tcl

So it looks like the problem is ultimately due to a limitation of
Tcl/Tk.

Yep, that seems to be the case. Not sure if that's still true on a
more recent Python, but it does look like you won't get astral
characters in tkinter on the one you're using.


[snip]
Tkinter in recent versions of Python can handle astral characters, at 
least back to Python 3.8, the oldest I have on my Windows PC.

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

Re: Decoding bytes to text strings in Python 2

[Chris Angelico via Python-list]

On Mon, 24 Jun 2024 at 08:20, Rayner Lucas via Python-list
 wrote:
>
> In article ,
> ros...@gmail.com says...
> >
> > If you switch to a Linux system, it should work correctly, and you'll
> > be able to migrate the rest of the way onto Python 3. Once you achieve
> > that, you'll be able to operate on Windows or Linux equivalently,
> > since Python 3 solved this problem. At least, I *think* it will; my
> > current system has a Python 2 installed, but doesn't have tkinter
> > (because I never bothered to install it), and it's no longer available
> > from the upstream Debian repos, so I only tested it in the console.
> > But the decoding certainly worked.
>
> Thank you for the idea of trying it on a Linux system. I did so, and my
> example code generated the error:
>
> _tkinter.TclError: character U+1f40d is above the range (U+-U+)
> allowed by Tcl
>
> So it looks like the problem is ultimately due to a limitation of
> Tcl/Tk.
Yep, that seems to be the case. Not sure if that's still true on a
more recent Python, but it does look like you won't get astral
characters in tkinter on the one you're using.

> I'm still not sure why it doesn't give an error on Windows and

Because of the aforementioned weirdness of old (that is: pre-3.3)
Python versions on Windows. They were built to use a messy, buggy
hybrid of UCS-2 and UTF-16. Sometimes this got you around problems, or
at least masked them; but it wouldn't be reliable. That's why, in
Python 3.3, all that was fixed :)

> instead either works (when UTF-8 encoding is specified) or converts the
> out-of-range characters to ones it can display (when the encoding isn't
> specified). But now I know what the root of the problem is, I can deal
> with it appropriately (and my curiosity is at least partly satisfied).

Converting out-of-range characters is fairly straightforward, at least
as long as your Python interpreter is correctly built (so, Python 3,
or a Linux build of Python 2).

"".join(c if ord(c) < 65536 else "?" for c in text)

> This has given me a much better understanding of what I need to do in
> order to migrate to Python 3 and add proper support for non-ASCII
> characters, so I'm very grateful for your help!
>

Excellent. Hopefully all this mess is just a transitional state and
you'll get to something that REALLY works, soon!

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

Re: Anonymous email users

[Sebastian Wells via Python-list]

On Fri, 14 Jun 2024 18:00:37 -0400, avi.e.gross wrote:

> I notice that in some recent discussions, we have users who cannot be
> replied to directly as their email addresses are not valid ones, and I
> believe on purpose. Examples in the thread I was going to reply to are:
>  
>   henha...@devnull.tb
>  
>   no.email@nospam.invalid
>  
>  
> candycanearter07@candycanearter07.nomail.afraid (user  is
> generated from /dev/urandom)
>  
> I know some here suggest that we only reply to the wider community and
> they have a point. But I think there is a role for having some
> conversations offline and especially when they are not likely to be
> wanted, or even tolerated, by many in the community.
>  
> Using such fake or invalid emails makes it hard to answer the person
> directly or perhaps politely ask them for more info on their request or
> discuss unrelated common interests. Worse, when I reply, unless I use
> reply-all, my mailer sends to them futilely. When I do the reply-all, I
> have to edit out their name or get a rejection.
>  

The spammers won the spam wars, so even if you have someone's real
e-mail address, that's no guarantee that you can contact them. You
certainly wouldn't be able to contact me at my real e-mail address,
unless you also had my phone number, so you could call me and tell
me that you sent me an e-mail, and what the subject line was so I
can find it. I don't even open my e-mail inbox unless there's a
specific message I'm expecting to find there right now.

With e-mail addresses being phone-validated, it's not easy to create
a new one either. And even if I did, you can't even trust e-mail 
providers not to give your address out to spammers.

The only function e-mail addresses serve now is to positively identify
the sender of a Usenet posting so he can be targeted for harassment,
lawsuits, or worse.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Decoding bytes to text strings in Python 2

[Rayner Lucas via Python-list]

In article , r...@zedat.fu-
berlin.de says...
> 
>   I didn't really do a super thorough deep dive on this,
>   but I'm just giving the initial impression without 
>   actually being familiar with Tkinter under Python 2,
>   so I might be wrong!
> 
>   The Text widget typically expects text in Tcl encoding,
>   which is usually UTF-8. 
> 
>   This is independent of the result returned by sys.get-
>   defaultencoding()! 
> 
>   If a UTF-8 string is inserted directly as a bytes object,
>   its code points will be displayed correctly by the Text 
>   widget as long as they are in the BMP (Basic Multilingual
>   Plane), as you already found out yourself.

Many thanks, you've helped me greatly in understanding what's happening. 
When I tried running my example code on a different system (Python 
2.7.18 on Linux, with Tcl/Tk 8.5), I got the error:

_tkinter.TclError: character U+1f40d is above the range (U+-U+) 
allowed by Tcl

So, as your reply suggests, the problem is ultimately a limitation of 
Tcl/Tk itself. Perhaps I should have spent more time studying the docs 
for that instead of puzzling over the details of character encodings in 
Python! I'm not sure why it doesn't give the same error on Windows, but 
at least now I know where the root of the issue is.

I am now much better informed about how to migrate the code I'm working 
on, so I am very grateful for your help.

Thanks,
Rayner
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Decoding bytes to text strings in Python 2

[Rayner Lucas via Python-list]

In article , 
ros...@gmail.com says...
> 
> If you switch to a Linux system, it should work correctly, and you'll
> be able to migrate the rest of the way onto Python 3. Once you achieve
> that, you'll be able to operate on Windows or Linux equivalently,
> since Python 3 solved this problem. At least, I *think* it will; my
> current system has a Python 2 installed, but doesn't have tkinter
> (because I never bothered to install it), and it's no longer available
> from the upstream Debian repos, so I only tested it in the console.
> But the decoding certainly worked.

Thank you for the idea of trying it on a Linux system. I did so, and my 
example code generated the error:

_tkinter.TclError: character U+1f40d is above the range (U+-U+) 
allowed by Tcl

So it looks like the problem is ultimately due to a limitation of 
Tcl/Tk. I'm still not sure why it doesn't give an error on Windows and 
instead either works (when UTF-8 encoding is specified) or converts the 
out-of-range characters to ones it can display (when the encoding isn't 
specified). But now I know what the root of the problem is, I can deal 
with it appropriately (and my curiosity is at least partly satisfied).

This has given me a much better understanding of what I need to do in 
order to migrate to Python 3 and add proper support for non-ASCII 
characters, so I'm very grateful for your help!

Thanks,
Rayner
-- 
https://mail.python.org/mailman/listinfo/python-list

How to go about a simple object grabbing in python (given coordinates of arms and objects)

[marc nicole via Python-list]

Hello to all of this magnificent community!

I have this problem I had already spent a few days on and still can't
figure out a proper solution.

So, given the x,y,z coordinates of a target object and the offset x,y,z of
arms of a robot, what is a good algorithm to perform to grab the object
between the hands (either from both sides or from below all using both
hands).

Specifically, my problem is applied to a NAO robot environment where I
retrieve a target object coordinates using the following code:

tracker_service= session.service("ALTracker")
xyz_pos = tracker_service.getTargetPosition(motion.FRAME_TORSO)


src:
http://doc.aldebaran.com/2-8/naoqi/motion/control-cartesian.html#motion-cartesian-effectors


Then I get to move the right arm towards nearby the object using the
following code:

effector = "RArm"

frame = motion.FRAME_TORSO
effector_offset =
almath.Transform(self.motion.getTransform(effector, frame, False))
effector_init_3d_position = almath.position3DFromTransform(
effector_offset)

target_3d_position = almath.Position3D(target_position)
move_3d = target_3d_position - effector_init_3d_position
moveTransform = almath.Transform.fromPosition(move_3d.x,
move_3d.y, move_3d.z)
target_transformer_list = list(moveTransform.toVector())
times = [2.0]
axis_mask_list = motion.AXIS_MASK_VEL
self.motion.transformInterpolations(effector, frame,
target_transformer_list, axis_mask_list, times).

src: 
http://doc.aldebaran.com/1-14/dev/python/examples/almath/index.html?highlight=offset
This question is specific to NAO environment but in general how to go
about this task? what is a most common algorithm used in this case? Do
I have to also get the side of the object in order to know where
exactly the arms should be placed?
-- 
https://mail.python.org/mailman/listinfo/python-list