Re: [Python-Dev] String concatenation
Is the only issue with this feature that you might accidentally miss a comma after a string in a sequence of strings? That seems like a significantly obscure scenario compared to the usefulness of the current syntax, for exactly the purpose Barry points out (which most people use all the time). I think the runtime concatenation costs are less important than the handiness of being able to break strings across lines without having to figure out where to put that '+' operator. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bytes.tohex in Python 3
Hi,
I'm confused as to how you represent a bytes object in hexadecimal in Python
3. Of course in Python 2, you use str.encode('hex') to go to hex, and
hexstr.decode('hex') to go from hex.
In Python 3, they removed "hex" as a codec (which was a good move, I think).
Now there's the static method bytes.fromhex(hexbytes) to go from hex. But I
haven't figured out any (easy) way to convert a byte string to hex. Is there
some way I haven't noticed, or is this an oversight?
The easiest thing I can think of currently is this:
''.join(hex(b)[2:] for b in mybytes)
I think there should be a bytes.tohex() method. I'll add this as a bug
report if it indeed is an oversight, but I thought I'd check here first to
make sure I'm not just missing something.
Matt
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Merges from 2.6 to 3.0?
Are big merges from the trunk still being made to the py3k branch? I checked in a change to csv.DictReader on the trunk yesterday evening. I will port it to py3k if necessary, but I was under the impression that the merge gnomes are constantly busy at work behind the scene. If this activity has been curtailed because we are nearly late betas or something, let me know and I'll do it myself. Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
On Sat, Aug 9, 2008 at 7:40 AM, <[EMAIL PROTECTED]> wrote: > Are big merges from the trunk still being made to the py3k branch? I > checked in a change to csv.DictReader on the trunk yesterday evening. I > will port it to py3k if necessary, but I was under the impression that the > merge gnomes are constantly busy at work behind the scene. If this activity > has been curtailed because we are nearly late betas or something, let me > know and I'll do it myself. They's still happening, as irregularly scheduled as ever. However if you think your change requires any kind of manual help to be merged, it's better to do the merge yourself for just that revision: svnmerge.py merge -rN. That way it'll be recorded as merged and a later big merge will skip it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.tohex in Python 3
Well, whether there's community support for this or not, I thought I'd have
a go at implementing this, so I did. I've submitted a feature request +
working patch to the bug tracker:
http://bugs.python.org/issue3532
Matt
PS. I mean
''.join("%02x" % b for b in mybytes)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
Guido> However if you think your change requires any kind of manual help Guido> to be merged, it's better to do the merge yourself for just that Guido> revision: svnmerge.py merge -rN. That way it'll be recorded Guido> as merged and a later big merge will skip it. Looks like there's a bit of manual work to do (replacing "try/finally" with "with", for example). I don't know what svnmerge.py is though and don't see it in my svn tools or my trunk sandbox: ~% cd ~/src/python/trunk/ trunk% find . -name svnmerge.py trunk% like svn /usr/bin/svn /usr/bin/svnadmin /usr/bin/svndumpfilter /usr/bin/svnlook /usr/bin/svnserve /usr/bin/svnsync /usr/bin/svnversion Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
Google for it. It's worth learning. :-) On Sat, Aug 9, 2008 at 9:37 AM, <[EMAIL PROTECTED]> wrote: > >Guido> However if you think your change requires any kind of manual help >Guido> to be merged, it's better to do the merge yourself for just that >Guido> revision: svnmerge.py merge -rN. That way it'll be recorded >Guido> as merged and a later big merge will skip it. > > Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). I don't know what svnmerge.py is though and don't see > it in my svn tools or my trunk sandbox: > >~% cd ~/src/python/trunk/ >trunk% find . -name svnmerge.py >trunk% like svn >/usr/bin/svn >/usr/bin/svnadmin >/usr/bin/svndumpfilter >/usr/bin/svnlook >/usr/bin/svnserve >/usr/bin/svnsync >/usr/bin/svnversion > > Skip > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.tohex in Python 3
On Sat, Aug 9, 2008 at 12:40 AM, Matt Giuca <[EMAIL PROTECTED]> wrote:
> I'm confused as to how you represent a bytes object in hexadecimal in Python
> 3. Of course in Python 2, you use str.encode('hex') to go to hex, and
> hexstr.decode('hex') to go from hex.
>
> In Python 3, they removed "hex" as a codec (which was a good move, I think).
> Now there's the static method bytes.fromhex(hexbytes) to go from hex. But I
> haven't figured out any (easy) way to convert a byte string to hex. Is there
> some way I haven't noticed, or is this an oversight?
>
> The easiest thing I can think of currently is this:
> ''.join(hex(b)[2:] for b in mybytes)
>
> I think there should be a bytes.tohex() method. I'll add this as a bug
> report if it indeed is an oversight, but I thought I'd check here first to
> make sure I'm not just missing something.
How about
import binascii
binascii.hexlify(b'abc')
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.tohex in Python 3
Hi Guido, Ah yes Martin just pointed this out on the tracker. I think it would still be worthwhile having the tohex method, if not just to counter the obscurity of the binascii.hexlify function (but for other reasons too). Also there's an issue with all the functions in binascii - they return bytes, not strings. Is this an oversight? (My version of tohex returns a str). See tracker: http://bugs.python.org/issue3532 Matt ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
> Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). Why that? Shouldn't the 2.6 code already use the with statement? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
On Sat, Aug 9, 2008 at 9:37 AM, <[EMAIL PROTECTED]> wrote: > >Guido> However if you think your change requires any kind of manual help >Guido> to be merged, it's better to do the merge yourself for just that >Guido> revision: svnmerge.py merge -rN. That way it'll be recorded >Guido> as merged and a later big merge will skip it. > > Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). I don't know what svnmerge.py is though and don't see > it in my svn tools or my trunk sandbox: > As always, the dev FAQ has the answer you are looking for: http://python.org/dev/faq/#how-do-i-merge-between-branches . ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
>> Looks like there's a bit of manual work to do (replacing >> "try/finally" with "with", for example). Martin> Why that? Shouldn't the 2.6 code already use the with statement? The csv test code uses try/finally on trunk but with on py3k. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
>> I don't know what svnmerge.py is ... > As always, the dev FAQ has the answer you are looking for: > http://python.org/dev/faq/#how-do-i-merge-between-branches . OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the changes with the commit message svnmerge generated. Am I supposed to block either the earlier revision (65605) from being merged from trunk to py3k or the later revision (65611) from being merged from py3k to trunk? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
If you use svnmerge properly you won't have to block anything in this case. Blocking is used to mark revs that are applied to 2.6 but should *not* apply to 3.0. We never merge from py3k to the trunk, only from the trunk to py3k. --Guido On Sat, Aug 9, 2008 at 12:50 PM, Skip Montanaro <[EMAIL PROTECTED]> wrote: >>> I don't know what svnmerge.py is ... > >> As always, the dev FAQ has the answer you are looking for: >> http://python.org/dev/faq/#how-do-i-merge-between-branches . > > OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the > changes with the commit message svnmerge generated. Am I supposed to block > either the earlier revision (65605) from being merged from trunk to py3k or > the later revision (65611) from being merged from py3k to trunk? > > Thx, > > Skip > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
> Martin> Why that? Shouldn't the 2.6 code already use the with statement? > > The csv test code uses try/finally on trunk but with on py3k. So why doesn't it use with on the trunk? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
Guido> If you use svnmerge properly you won't have to block anything in Guido> this case. Let's assume I used it correctly. (That, of course, remains to be seen.) What about the checkin I did will tell someone running svnmerge later that r65605 has already been merged to py3k? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
Martin> Why that? Shouldn't the 2.6 code already use the with statement? >> The csv test code uses try/finally on trunk but with on py3k. Martin> So why doesn't it use with on the trunk? I don't know. I sure wasn't going to change that code at this point. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
[EMAIL PROTECTED] schrieb: Guido> If you use svnmerge properly you won't have to block anything in Guido> this case. Let's assume I used it correctly. (That, of course, remains to be seen.) What about the checkin I did will tell someone running svnmerge later that r65605 has already been merged to py3k? svnmerge stores information about merged and blocked revisions in SVN properties of the root directory. In your case, you didn't commit the property change, so svnmerge doesn't assume 65605 as integrated yet. If you still have the property change in your working copy, please commit it. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
Georg> svnmerge stores information about merged and blocked revisions in Georg> SVN properties of the root directory. In your case, you didn't Georg> commit the property change, so svnmerge doesn't assume 65605 as Georg> integrated yet. If you still have the property change in your Georg> working copy, please commit it. Ah, ok. Done. I guess I shouldn't have specified the files to commit. I should have committed everything. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merges from 2.6 to 3.0?
[EMAIL PROTECTED] schrieb: Georg> svnmerge stores information about merged and blocked revisions in Georg> SVN properties of the root directory. In your case, you didn't Georg> commit the property change, so svnmerge doesn't assume 65605 as Georg> integrated yet. If you still have the property change in your Georg> working copy, please commit it. Ah, ok. Done. I guess I shouldn't have specified the files to commit. I should have committed everything. Yep; thankfully svnmerge makes sure the working copy is clean before merging. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Dealing with mimetools usage in the stdlib
On my quest to remove warnings raised in 2.6 when Python is run with -3, the issue of dealing with mimetools has come up in terms of backwards-compatibility. For instance, in BaseHTTPServer, the headers attribute on BaseHTTPRequestHandler is an instance of mimetools.Message. But in 3.0 it is an instance of http.client.HTTPMessage. So my question is, should 2.6 be changed to match 3.0, or should deprecation warnings for mimetools (and possibly other modules) just be silenced so as to not risk breaking backwards-compatibility? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dealing with mimetools usage in the stdlib
On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On my quest to remove warnings raised in 2.6 when Python is run with > -3, the issue of dealing with mimetools has come up in terms of > backwards-compatibility. For instance, in BaseHTTPServer, the headers > attribute on BaseHTTPRequestHandler is an instance of > mimetools.Message. But in 3.0 it is an instance of > http.client.HTTPMessage. > > So my question is, should 2.6 be changed to match 3.0, or should > deprecation warnings for mimetools (and possibly other modules) just > be silenced so as to not risk breaking backwards-compatibility? Just silence them. The warnings are an aid for finding bugs, not an excuse to create more bugs. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
