Re: if bytes != str:

_bytes(s): > if bytes != str: > if type(s) == str: > return s.encode('utf-8') > return s > > def to_str(s): > if bytes != str: > if type(s) == bytes: > return s.decode('utf-8') >

Re: if bytes != str:

ob/master/src/ssrlink.py> > > In this script, there are the following two customized functions: > > > -- > def to_bytes(s): > if bytes != str: > if type(s) == str: > return s.encode('utf-8') > return s > > def

Re: if bytes != str:

On 8/4/19 10:56 AM, Hongyi Zhao wrote: Hi, I read and learn the the following code now: https://github.com/shadowsocksr-backup/shadowsocksr-libev/blob/master/src/ ssrlink.py In this script, there are the following two customized functions: -- def to_bytes(s): if bytes != str

if bytes != str:

Hi, I read and learn the the following code now: https://github.com/shadowsocksr-backup/shadowsocksr-libev/blob/master/src/ ssrlink.py In this script, there are the following two customized functions: -- def to_bytes(s): if bytes != str: if type(s) == str

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: New changeset 5b76bdba071e7bbd9fda0b9b100d1506d95c04bd by Serhiy Storchaka in branch 'master': bpo-31993: Do not use memoryview when pickle large strings. (#5154)

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Serhiy Storchaka : -- pull_requests: +5009 ___ Python tracker ___ ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: New changeset 0a2da50e1867831251fad75377d0f10713eb6301 by Serhiy Storchaka in branch 'master': bpo-31993: Do not create frames for large bytes and str objects (#5114)

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: I'll create a separate PR for the memoroview issue after merging PR 5114. -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: > What do you mean? Large bytes and strings was written inside a frame when serialize by dumps(). dump() (as well as Python implementations of dumps() and dump()) write them outside of a frame. --

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: PR 5114 implements this when serialize in C into memory. -- resolution: fixed -> stage: resolved -> patch review status: closed -> open ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: > Humm, this feature doesn't work with C implementation. What do you mean? -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Serhiy Storchaka : -- pull_requests: +4980 ___ Python tracker ___ ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: Humm, this feature doesn't work with C implementation. -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Thanks for the very helpful feedback and guidance during the review. -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: Definitely! Thank you for your contribution :-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Shall we close this issue now that the PR has been merged to master? -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: New changeset 3cd7c6e6eb43dbd7d7180503265772a67953e682 by Serhiy Storchaka (Olivier Grisel) in branch 'master': bpo-31993: Do not allocate large temporary buffers in pickle dump. (#4353)

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: Agreed. We shouldn't issue very small writes, but 64 kB is generally considered a reasonable buffer size for many kinds of I/O. Besides, it wouldn't be difficult to make the target frame size configurable if a use case arose for it, but I

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Flushing the buffer at each frame commit will cause a medium-sized write every 64kB on average (instead of one big write at the end). So that might actually cause a performance regression for some users if the individual file-object

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: Framing was originally intended to improve unpickling (since you don't have to issue lots of tiny file reads anymore). No objection to also improve pickling, though :-) -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: > While we are here, wouldn't be worth to flush the buffer in the C > implementation to the disk always after committing a frame? This will save a > memory when dump a lot of small objects. I think it's a good idea. The C pickler

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Thanks Antoine, I updated my code to what you suggested. -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: While we are here, wouldn't be worth to flush the buffer in the C implementation to the disk always after committing a frame? This will save a memory when dump a lot of small objects. --

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: > I would like to update the `write_utf8` function but I would need to find a > way to wrap `const char* data` as a PyBytes instance without making a memory > copy to be able to pass it to my `_Pickle_write_large_bytes`. You should pass it

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Alright, I found the source of my refcounting bug. I updated the PR to include the C version of the dump for PyBytes. I ran Serhiy's microbenchmarks on the C version and I could not detect any overhead on small bytes objects while I

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: I have tried to implement the direct write bypass for the C version of the pickler but I get a segfault in a Py_INCREF on obj during the call to memo_put(self, obj) after the call to _Pickler_write_large_bytes. Here is the diff of

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: BTW, I am looking at the C implementation at the moment. I think I can do it. -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: Nice! I have got virtually the same code as your intermediate variant, but your final variant event better! -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Alright, the last version has now ~4% overhead for small bytes. -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Actually, I think this can still be improved while keeping it readable. Let me try again :) -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: I have pushed a new version of the code that now has a 10% overhead for small bytes (instead of 40% previously). It could be possible to optimize further but I think that would render the code much less readable so I would be

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: This speeds up pickling large bytes objects. $ ./python -m timeit -s 'import pickle; a = [bytes([i%256])*100 for i in range(256)]' 'with open("/dev/null", "wb") as f: pickle._dump(a, f)' Unpatched: 10 loops, best of 5: 20.7

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: I'll try to write the C implementation. Maybe it will use other heuristic. -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: In my last comment, I also reported the user times (not spend in OS level disk access stuff): the code of the PR is on the order of 300-400ms while master is around 800ms or more. -- ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: Actually the time varies too much between runs. 1.641s ... 8.475s ... 12.645s -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: So we're saving memory and CPU time. Cool! -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: More benchmarks with the unix time command: ``` (py37) ogrisel@ici:~/code/cpython$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. (py37) ogrisel@ici:~/code/cpython$ time python

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: Note that the time difference is not significant. I rerun the last command I got: ``` (py37) ogrisel@ici:~/code/cpython$ python ~/tmp/large_pickle_dump.py --use-pypickle Allocating source data... => peak memory usage: 2.014 GB

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: But the total runtime is higher? (6 s. vs. 5 s.) Can you post the CPU time? (as measured by `time`, for example) -- ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Olivier Grisel added the comment: I wrote a script to monitor the memory when dumping 2GB of data with python master (C pickler and Python pickler): ``` (py37) ogrisel@ici:~/code/cpython$ python ~/tmp/large_pickle_dump.py Allocating source data... => peak memory

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Serhiy Storchaka added the comment: Would be nice to see benchmarks. And what about C version? -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Antoine Pitrou : -- stage: needs patch -> patch review ___ Python tracker ___ ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: As for the C pickler, currently it dumps the whole pickle into an internal buffer before calling write() at the end. You may want to make writing more incremental. See Modules/_pickler.c (especially _Pickler_Write()). -- stage:

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Change by Roundup Robot : -- keywords: +patch pull_requests: +4309 stage: needs patch -> patch review ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: Of course, +1 for fixing this. -- ___ Python tracker ___

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

Antoine Pitrou added the comment: You don't need to add a test for a performance enhancement. -- stage: -> needs patch type: resource usage -> performance versions: -Python 3.4, Python 3.5, Python 3.6, Python 3.8 ___ Python tracker

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

kipped on my 16 GB laptop. -- components: Library (Lib) messages: 305975 nosy: Olivier.Grisel, pitrou priority: normal severity: normal status: open title: pickle.dump allocates unnecessary temporary bytes / str type: resource usage versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7,

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

R. David Murray added the comment: For the record, encode_quopri was fixed in #14360. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___

[issue16738] Comparisons difference: bytes with bytes, str with str

: normal severity: normal status: open title: Comparisons difference: bytes with bytes, str with str type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16738

[issue16738] Comparisons difference: bytes with bytes, str with str

Christian Heimes added the comment: That's the correct behaviour. Iteration and item access of bytes don't return bytes but a small number, e.g. b[0] returns 116 and not b't'. b = b't' b[0] in [b] False b[0] 116 ord(b) 116 But: b in [b] True -- nosy: +christian.heimes

[issue15380] bytes/str mismatch in distribute

: Distutils messages: 165693 nosy: eric.araujo, mark, tarek priority: normal severity: normal status: open title: bytes/str mismatch in distribute type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15380

[issue15380] bytes/str mismatch in distribute

Ned Deily n...@acm.org added the comment: Distribute is not part of Distutils. According to its PyPI page (http://pypi.python.org/pypi/distribute#feedback-and-getting-involved), the project has its own issue tracker at https://bitbucket.org/tarek/distribute/issues/ -- nosy:

[issue15380] bytes/str mismatch in distribute

Changes by Ned Deily n...@acm.org: -- stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15380 ___ ___ Python-bugs-list

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Matt Joiner anacro...@gmail.com: -- nosy: +anacrolix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Georg Brandl ge...@python.org added the comment: The new test is faulty; it appears to be specific to the timezone of the patch submitter. The library fix should go in nevertheless, if you could add a correct test, Alexander, it would be great. -- priority: normal - release blocker

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Attached patch fixes the test (hopefully we don't have to support systems with non-POSIX epoch) and cleans up whitespace. -- resolution: - accepted stage: patch review - commit review Added file:

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file20604/issue10939.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Added file: http://bugs.python.org/file20605/issue10939.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in revision 88231. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Merged to 3.1 in r88233. -- nosy: +benjamin.peterson resolution: accepted - fixed stage: commit review - committed/rejected versions: +Python 3.1 ___ Python tracker

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Joe Peterson j...@skyrush.com added the comment: Good catch on the test. Note that for issue 10941, we'll want a new non-timezone-dependent test case that can catch the DST-related problem. I'll post a new patch to issue 10941 now and describe this some more there. --

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: It looks like my test is not robust enough: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/298 -- ___ Python tracker rep...@bugs.python.org

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Some systems don't like times too close to epoch. Fixed in revision 88239. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Joe Peterson j...@skyrush.com added the comment: Alexander, looks like you hit a weirdness in the Europe/London timezone for dates before 31-Oct-1971, as if DST was in effect even in winter. And the fail of the test is caused by the same bug that causes issue 10941: the use of mktime to

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Joe Peterson j...@skyrush.com added the comment: More info on the Europe/London near the epoch thing (there is no weirdness in the tz stuff - it's just issue 10941 causing the test to fail)... I looked at the sources for the tz data, and here is the definition for Europe/London: # Zone NAME

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Sat, Jan 29, 2011 at 5:48 PM, Joe Peterson rep...@bugs.python.org wrote: .. Note that this also exposes another problem with Time2Internaldate(), since it uses time.timezone/time.altzone, which are only valid for the

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Joe Peterson j...@skyrush.com: Removed file: http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Joe Peterson j...@skyrush.com: Added file: http://bugs.python.org/file20588/imaplib_Internaldate2tuple_bytes_fixes_python32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- assignee: belopolsky - georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10939 ___

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Georg, This is an obvious artifact of an untested py3k port. Can this go in 3.2? The patch looks good except for a long line in the test which I can take care of. -- assignee: - belopolsky nosy: +belopolsky,

[issue10939] imaplib: Internaldate2tuple fails to parse month and does not work with negative TZ offset due to bytes/str issues

: imaplib_Internaldate2tuple_bytes_fixes_python32.patch keywords: patch messages: 126499 nosy: lavajoe priority: normal severity: normal status: open title: imaplib: Internaldate2tuple fails to parse month and does not work with negative TZ offset due to bytes/str issues type: behavior versions: Python 3.2 Added file

[issue10939] imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

Changes by Joe Peterson j...@skyrush.com: -- title: imaplib: Internaldate2tuple fails to parse month and does not work with negative TZ offset due to bytes/str issues - imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes

[issue8897] sunau bytes / str TypeError in Py3k

Thomas Jollans tho...@jollans.com added the comment: Attached is a patch against the current py3k trunk that fixes this. (as far as I can tell) -- keywords: +patch Added file: http://bugs.python.org/file17580/sunau-bytes.diff ___ Python tracker

[issue8897] sunau bytes / str TypeError in Py3k

Thomas Jollans tho...@jollans.com added the comment: test case for sunau, as requested. Loosely based on test_wave. -- Added file: http://bugs.python.org/file17582/sunau-test.diff ___ Python tracker rep...@bugs.python.org

[issue8897] sunau bytes / str TypeError in Py3k

STINNER Victor victor.stin...@haypocalc.com added the comment: test case for sunau, as requested. Loosely based on test_wave. Ok great. Commited to py3k (r81809) and 3.1 (r81810). -- resolution: - fixed status: open - closed ___ Python tracker

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Forest Bond for...@alittletooquiet.net added the comment: Attaching patch from reported duplicate issue8896. -- nosy: +forest_atq Added file: http://bugs.python.org/file17551/python-email-encoders-base64-str.patch ___ Python tracker

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Forest Bond for...@alittletooquiet.net added the comment: Note that my patch is roughly the same as the original posted by haypo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

R. David Murray rdmur...@bitdance.com added the comment: Yes, but yours was better formatted, so I used it :) Thanks for the patch. Applied in r81685 to py3k, and r81686. -- resolution: accepted - fixed stage: patch review - committed/rejected status: open - closed

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

R. David Murray rdmur...@bitdance.com added the comment: @garazi111: if you have an example where quopri fails, please open a new issue for it. I suspect you are right that there is a problem there. -- ___ Python tracker rep...@bugs.python.org

[issue8897] sunau bytes / str TypeError in Py3k

this, as does the above code in Python 2.6. Au_read.readframes correctly returns a bytes. I haven't tested this on a development version of Python. -- components: Library (Lib) messages: 107081 nosy: tjollans priority: normal severity: normal status: open title: sunau bytes / str TypeError in Py3k

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

STINNER Victor victor.stin...@haypocalc.com added the comment: I wrote a patch for base64.b64encode() to accept str (str is encoded to utf-8): patch attached to #4768. It should fix this issue, but we can add the tests of email_base64_bytes.patch. --

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by R. David Murray rdmur...@bitdance.com: -- priority: high - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

garazi111 garazi...@yahoo.fr added the comment: Hi, I think the bug is also present in the function encode_quopri which should look like this : def encode_quopri(msg): Encode the message's payload in quoted-printable. Also, add an appropriate Content-Transfer-Encoding header.

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Éric Araujo mer...@netwok.org: -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list mailing

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Antoine Pitrou pit...@free.fr: -- priority: - high stage: - patch review versions: +Python 3.1, Python 3.2 -Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by R. David Murray rdmur...@bitdance.com: -- assignee: barry - r.david.murray resolution: - accepted type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Stac stac_agen...@yahoo.fr added the comment: Hello, This patch has never been commited. I tested today with the 3.1 branch (and checked in the lib code). Is there a better way to attach images in an email ? Thanks in advance for your help, Regards, Stac -- nosy: +stac

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Shashwat Anand anand.shash...@gmail.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Shashwat Anand anand.shash...@gmail.com: -- nosy: +l0nwlf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by James Brotchie brotc...@gmail.com: -- nosy: +brotchie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

STINNER Victor victor.stin...@haypocalc.com added the comment: I think the library function base64.b64encode() should return a string, not bytes. Yes, in the email module, the payload is an unicode string, not a bytes string. We have to be able to concatenate headers (eg. Content-Type:

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by STINNER Victor victor.stin...@haypocalc.com: -- keywords: +patch Added file: http://bugs.python.org/file12525/email_base64_bytes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

: Library (Lib) messages: 78464 nosy: beazley severity: normal status: open title: email.generator.Generator object bytes/str crash - b64encode() bug? type: crash versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Changes by Benjamin Peterson benja...@python.org: -- assignee: - barry nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___

[issue4338] TypeError (bytes/str) in distutils command upload

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Martin, do you still have remarks about this patch? Can we apply it? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4338 ___

[issue4338] TypeError (bytes/str) in distutils command upload

Martin v. Löwis [EMAIL PROTECTED] added the comment: The patch is fine, please apply. -- keywords: -needs review resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4338 ___

[issue4338] TypeError (bytes/str) in distutils command upload

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Fixed in r67308. -- resolution: accepted - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4338 ___

  1   2   >