[issue1525919] email package quoted printable behaviour changed

2008-09-27 Thread Asheesh Laroia

Asheesh Laroia <[EMAIL PROTECTED]> added the comment:

Another way to see this issue is that the email module double-encodes
when one attempts to use quoted-printable encoding.  This has to be
worked around by e.g. MoinMoin.

It's easy to get proper base64-encoded output of email.mime.text:

>>> mt = email.mime.text.MIMEText('Ta mère', 'plain', 'utf-8')
>>> 'Content-Transfer-Encoding: base64' in mt.as_string()
True
>>> mt.as_string().split('\n')[-2]
'VGEgbcOocmU='

There we go, all nice and base64'd.

I can *not* figure out how to get quoted-printable-encoding.  I found 
http://docs.python.org/lib/module-email.encoders.html , so I thought
great - I'll just encode my MIMEText object:

>>> email.encoders.encode_quopri(mt)
>>> 'Content-Transfer-Encoding: quoted-printable' in mt.as_string()
True

Great!  Except it's actually double-encoded, and the headers admit to as
much.  You see here that, in addition to the quoted-printable header
just discovered, there is also a base64-related header, and the result
is not strictly QP encoding but QP(base64(payload)).

>>> 'Content-Transfer-Encoding: base64' in mt.as_string()
True
>>> mt.as_string().split('\n')[-2]
'VGEgbcOocmU=3D'

It should look like:

>>> quopri.encodestring('Ta mère')
'Ta m=C3=A8re'

I raised this issue on the Baypiggies list
<http://mail.python.org/pipermail/baypiggies/2008-September/003983.html>, but
luckily I found this here bug.  This is with Python 2.5.2-0ubuntu1 from
Ubuntu 8.04.

[EMAIL PROTECTED]:~ $ python --version
Python 2.5.2

If we can come to a decision as to how this *should* work, I could
contribute a patch and/or tests to fix it.  I could even perhaps write a
new section of the Python documentation of the email module explaining this.

--
nosy: +paulproteus

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1525919>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7794] Document zipfile and directory execution in What's New for 2.6/3.1

2010-02-20 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Hey dudes and/or dudettes,

I think this is already done. Check out this old commit to trunk:

http://svn.python.org/view/python/trunk/Misc/NEWS?r1=58963&r2=59039&pathrev=59039
 

When I check out Python trunk right now, Line 3759 of Misc/NEWS mentions this 
new feature.

Therefore, I think this bug can be closed -- it's already documented.

If it should instead be documented in some *other* way, let me know and I'll 
see if I can do it!

--
nosy: +Asheesh.Laroia

___
Python tracker 
<http://bugs.python.org/issue7794>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6414] struct module : processor endianness descriptions misleading

2010-02-20 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Hey all,

I (a person who just wandered by) think that Alexey Shamrin's suggested text is 
great.

For that reason, I have turned it into a unified diff created by 'svn diff'.

I hope that would help move this bug along!

I'm attaching that patch against trunk right now.

--
keywords: +patch
nosy: +Asheesh.Laroia
Added file: http://bugs.python.org/file16272/issue6416-trunk.patch

___
Python tracker 
<http://bugs.python.org/issue6414>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6414] struct module : processor endianness descriptions misleading

2010-02-20 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

I'm attaching (basically) the same patch, this time against the py3k branch.

I'm open to improvements to the text. If the text is okay, please just ship 
these!

Sincerely,

A dude sitting in an open space at PyCon.

--
Added file: http://bugs.python.org/file16273/issue6414-py3k.patch

___
Python tracker 
<http://bugs.python.org/issue6414>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6538] MatchObject is not a hyperlink in the 're' module documentation

2010-02-25 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Hey all,

I think this is ready. Can someone review the patch?

--
nosy: +Asheesh.Laroia

___
Python tracker 
<http://bugs.python.org/issue6538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6538] MatchObject is not a hyperlink in the 're' module documentation

2010-02-25 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Ryan -- would you take a further look at this?

--

___
Python tracker 
<http://bugs.python.org/issue6538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6538] MatchObject is not a hyperlink in the 're' module documentation

2010-03-08 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Hey Ryan,

I took a look at the diff you attached here. It looks like you did 

There are some whitespace-only changes -- for example, you remove and then 
re-insert the line beginning with "The name of the last matched capturing 
group".

Can you re-submit your most recent patch without the unneeded whitespace-only 
changes?

There's a light at the end of the tunnel!

--

___
Python tracker 
<http://bugs.python.org/issue6538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6538] MatchObject is not a hyperlink in the 're' module documentation

2010-03-09 Thread Asheesh Laroia

Asheesh Laroia  added the comment:

Er, ignore my comment then!

If this is reviewed, can it get committed?

--

___
Python tracker 
<http://bugs.python.org/issue6538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40692] Adjust test_concurrent_futures to run more of its tests if multiprocessing.synchronize is missing

2020-05-19 Thread Asheesh Laroia


New submission from Asheesh Laroia :

Some parts of test_concurrent_futures make sense to run even on Python builds 
where multiprocessing.synchronize is absent. At the moment, 
test_concurrent_futures.py skips all tests in the file if 
multiprocessing.synchronize is missing from the Python build. I have a patch to 
enable more tests, which I'll submit as a GitHub pull request.

The reason I want this patch is while working on CPython on Android, I saw that 
test_concurrent_futures refused to run its test suite, and I became very afraid 
that this meant that asyncio on CPython on Android was doomed. In fact, I was 
afraid for no reason. I want future people porting CPython to be less scared 
than I was. :)

I discovered that the only part of concurrent.futures that requires 
multiprocessing.synchronize is concurrent.futures.ProcessPoolExecutor.

concurrent.futures.ProcessPoolExecutor already has a way to check at runtime if 
it can work on the host system, so this patch leans on that.

This patch fixes a few other tests to skip themselves in the case that 
ProcessPoolExecutor cannot function.

I tested this by building CPython (with my patch) with adding a configure flag 
on macOS:

$ ./configure --with-pydebug --with-openssl=$(brew --prefix openssl) 
ac_cv_posix_semaphores_enabled=no

Why multiprocessing.synchronize is missing
--

multiprocessing.synchronize imports _multiprocessing.SemLock, which is based on 
a libc function called sem_open(), which implements named semaphores, which 
allows the creation of lock-esque counters that can be used from multiple 
processes. multiprocessing.c currently only creates the SemLock property if 
sem_open() is considered "working" through a check in ./configure; I've 
short-circuited that check above to be a "no".

On Android, sem_open() exists but simply returns ENOSYS; see its implementation 
here: 
https://android.googlesource.com/platform/external/pthreads/+/master/sem_open.c

Android isn't the only platform missing sem_open()

Past work
-

issue3770 is an older conversation about a related issue. issue3770 has also 
attracted comments from someone who wants CPython's test suite to run to 
completion on their platform lacking sem_open() and therefore lacking 
multiprocessing.synchronize. This patch should solve their problem, I hope.

Future work
---

Automated testing: In order to prevent regressions, I'm interested in hosting a 
buildbot for at least one year, hopefully in perpetuity, on which we call 
./configure with ac_cv_posix_semaphores_enabled=no.

I'd like to improve the error message when the user imports 
multiprocessing.synchronize so it points at some new documentation text that I 
(or someone) adds to CPython, rather than the issue number. I'm OK taking on 
the work of writing those docs in a follow-up issue if we merge this.

Thanks
--

Thanks to Zachary Ware for discussing this with me in an CPython contributor 
office hours time slot before I filed the issue. Thanks to Dr. Russell 
Keith-Magee, Glyph Lefkowitz, Nathaniel Smith, and Geoffrey Thomas for informal 
conversations and technical research.

--
components: Tests, asyncio
messages: 369393
nosy: asheesh, asvetlov, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Adjust test_concurrent_futures to run more of its tests if 
multiprocessing.synchronize is missing
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40692>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com