[Python-Dev] Error in PEP3118?
Hi Travis,
The pep contains this sample:
"""
Nested array
::
struct {
int ival;
double data[16*4];
}
"""i:ival:
(16,4)d:data:
"""
"""
I think it is wrong and must be changed to the following; is this correct?
"""
Nested array
::
struct {
int ival;
double data[16][4];
}
"""i:ival:
(16,4)d:data:
"""
"""
Thomas
___
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] What to do for bytes in 2.6?
Guido van Rossum wrote: > Oh, you won't. Just don't use the -3 command-line flag and don't put > "from __future__ import " at the top of your modules, and > you won't have to change your ways at all. You can continue to > distribute your packages in 2.5 syntax that will also work with 2.6, > and your users will be happy (as long as they don't want to use your > code on 3.0 -- but if you want to give them that, *that* is when you > will finally be forced to face the issue. :-) from __future__ import bytes ? What should the __future__ statement change? * "" returns unicode instead of str * b"" is allowed and returns bytes (a new subclass of str) * u"" is still allowed and returns unicode, too. * The str built-in is not available. > Note that I believe that the -3 flag should not change semantics -- it > should only add warnings. Semantic changes must either be backwards > compatible or be requested explicitly with a __forward__ import (which > 2to3 can remove). Agreed! Should the -3 flag also warn about deprecated features which can easily migrated with 2to3? In the past a warning for `` (back ticks) were added. The feature is deprecated but the migration is very simple. A 2to26 fixer may be worth implementing, too. It could migrate minor changes like `` -> repr and "except egg, spam" -> "except egg as spam". Christian ___ 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] PEP 370, open questions
Christian Heimes cheimes.de> writes: > > I assume ~/.local was first introduced by the freedesktop.org people. On > my box it's only used for some desktop related apps like > ~/.local/share/Trash or XFC4. Same here, only ~/.local/share is used (on two boxes, one Mandriva and one Ubuntu). ___ 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] building _ctypes in trunk fails first time around
Guido van Rossum wrote: > If I run "make clean" and then "make", builting _ctypes fails with this > message: > > *** WARNING: renaming "_ctypes" since importing it failed: No module > named _weakref > > Typing "make" a second time fixes this -- it seems a simple matter of > _ctypes being built before _weakref. I applied a quick fix in r60043. Christian ___ 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] PEP 370, open questions
Suraj Barkale wrote: > Can this be changed into using %APPDATA% by default and changing to > %HOMEDRIVE%%HOMEPATH% based on some MSI switch? I'll stick to APPDATA but I'm going to introduce a new env var PYTHONUSERBASE. It overwrites the path to the base directory and allows users (and companies) to adjust the user directory for all Python versions. Christian ___ 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] What to do for bytes in 2.6?
Guido van Rossum wrote: > I don't think any of that is necessary. I would rather have the > following two in the language by default (see my response to Terry and > Raymond): > > bytes is an alias for str (not even a subclass) > b"" is an alias for "" Ah, you like to keep it simple. The aliases are easily to implement. Give me twenty minutes to implement it and write some unit tests. > There is only one thing I'd like -3 to warn about regarding except > clauses: if the 'err' variable is used past the end of the except > clause. That is a true semantic change that 2to3 cannot easily fix or > flag. Consider this an example of how 2to3 and -3 should augment each > other. Several warnings have to be removed: ``, callable and maybe more. Christian ___ 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] What to do for bytes in 2.6?
On Jan 18, 2008 12:27 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Oh, you won't. Just don't use the -3 command-line flag and don't put > > "from __future__ import " at the top of your modules, and > > you won't have to change your ways at all. You can continue to > > distribute your packages in 2.5 syntax that will also work with 2.6, > > and your users will be happy (as long as they don't want to use your > > code on 3.0 -- but if you want to give them that, *that* is when you > > will finally be forced to face the issue. :-) > > from __future__ import bytes ? What should the __future__ statement change? > > * "" returns unicode instead of str > * b"" is allowed and returns bytes (a new subclass of str) > * u"" is still allowed and returns unicode, too. > * The str built-in is not available. I don't think any of that is necessary. I would rather have the following two in the language by default (see my response to Terry and Raymond): bytes is an alias for str (not even a subclass) b"" is an alias for "" > > Note that I believe that the -3 flag should not change semantics -- it > > should only add warnings. Semantic changes must either be backwards > > compatible or be requested explicitly with a __forward__ import (which > > 2to3 can remove). > > Agreed! Should the -3 flag also warn about deprecated features which can > easily migrated with 2to3? In the past a warning for `` (back ticks) > were added. The feature is deprecated but the migration is very simple. Personally, I think such warnings are misguided. -3 should augment 2to3, not duplicate its work. > A 2to26 fixer may be worth implementing, too. It could migrate minor > changes like `` -> repr and "except egg, spam" -> "except egg as spam". 2to3 with selected options can do that already. But again, I don't see the point -- 2.6 code can just use 2.5 syntax and 2to3 will take care of the migration. There is only one thing I'd like -3 to warn about regarding except clauses: if the 'err' variable is used past the end of the except clause. That is a true semantic change that 2to3 cannot easily fix or flag. Consider this an example of how 2to3 and -3 should augment each other. -- --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] What to do for bytes in 2.6?
On Jan 17, 2008 11:24 PM, Thomas Heller <[EMAIL PROTECTED]> wrote: > Is the bytes type required for PEP3118 'Revising the buffer protocol'? I don't think so. I would like to see this PEP backported (but keep the old 'buffer' of course for b/w compatibility). Whenever this PEP talks about bytes we can just use str/PyString in the backport. > I just started to work on implementing this PEP for ctypes, in the > hope that these changes can be merged into trunk. Remember that the trunk ought to remain backwards compatible with 2.5 -- 2.6 should not break code that worked under 2.5, since we want as many users as possible to feel comfortable with upgrading to 2.6. -- --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] What to do for bytes in 2.6?
On Jan 17, 2008 9:30 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | Is it reading text or binary data from stream blah? We can't tell. If > | it's meant to be reading text, 2to3 should leave it alone. But if it's > | meant to be reading binary data, 2to3 should change the string > | literals to bytes literals (b"" in this case). (If it's used for both, > | there's no hope.) As it stands, 2to3 hasn't a chance to decide what to > | do, so it will leave it alone -- but the "translated" code will be > | wrong if it was meant to be reading bytes. > > It seems that the main purpose of adding bytes (as more or less a > synonym for str when used as bytes) is to aid 2to3 translation. > So I think I would favor it being part of a future import. > > | Note that I believe that the -3 flag should not change semantics -- it > | should only add warnings. Semantic changes must either be backwards > | compatible or be requested explicitly with a __forward__ import (which > | 2to3 can remove). > > Were you planning to make bytes a __future__ (or __forward__?) import? > I think making it so should satisfy Raymond's concerns. Even if whatever > you eventually do is technically backwards compatible, he is suggesting > that conceptually, it is not. I see some validity to that view. While it *could* be made conditional on a __future__ import, the cost of those (both in terms of implementing them and using them) is rather high so I'd prefer it to be always available. Given Raymond's later response, I'm not sure it's worth the effort. On Jan 17, 2008 9:44 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > having b"" and bytes as aliases for "" and > > str in 2.6 would mean that we could write 2.6 code that correctly > > expresses the use of binary data -- and we could use u"" and unicode > > for code using text, and 2to3 would translate those to "" and str and > > the code would be correct 3.0 text processing code. > > I see. There's a healthy benefit for 2to3 translation that cannot be > accomplished in any other way. This may potentially more than offset the > negative impact to the 2.x world where it complexifies the language > without any immediate payoff. > > FWIW, I'm sold on the rationale. Hopefully, this can be confined > to just annotation and aliasing but not porting back any C API > changes or code that depends on the bytes/text distinction. I'm fine with only making this a superficial veneer: b"" and bytes as aliases for "" and str. However Thomas Heller's response requires more thought. > I worry > that as soon as the annotation is made available, it will ripple > throughout the code and pervade the language so that it cannot > be ignored by Py2.6 coders. It's a bit of a Pandora's Box. Well, that's one opinion against another. And I presume by now you have read Glyph's enthusiastic response. Getting Twisted on 3.0 is a big enabler for getting other 3rd party packages an apps on board! > > Just being able to (voluntarily! on a > > per-module basis!) use a different type name and literal style for > > data could help forward-looking programmers get started on making the > > distinction clear, thus getting ready for 3.0 without making the jump > > just yet (or maintaining a 2.6 and a 3.0 version of the same package > > easily, using 2to3 to automatically generate the 3.0 version from the > > 2.6 code base). > > Are we going to be "forward-looking" and change all of the > standard library modules? Is this going to pop-up everywhere > and become something you have to know about whether or > not you're a volunteering forward-looking programmer? I hope not. I have no desire to fix up the standard library cosmetically, and I don't see the need -- the standard library has already been forward ported to 3.0, so the rationale just doesn't apply. -- --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] What to do for bytes in 2.6?
2008/1/18, Guido van Rossum <[EMAIL PROTECTED]>: > I don't think any of that is necessary. I would rather have the > following two in the language by default (see my response to Terry and > Raymond): > > bytes is an alias for str (not even a subclass) > b"" is an alias for "" +1 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Summary of Tracker Issues
ACTIVITY SUMMARY (01/11/08 - 01/18/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1329 open (+31) / 11986 closed (+15) / 13315 total (+46) Open issues with patches: 437 Average duration of open issues: 673 days. Median duration of open issues: 989 days. Open Issues Breakdown open 1310 (+31) pending19 ( +0) Issues Created Or Reopened (47) ___ PEP 754 update 01/11/08 http://bugs.python.org/issue1795created tiran ctypes should allow a tuple when an Array is expected01/11/08 CLOSED http://bugs.python.org/issue1796created theller patch ctypes function pointer enhancements 01/11/08 http://bugs.python.org/issue1797created theller patch Add ctypes calling convention that allows safe access of errno 01/11/08 http://bugs.python.org/issue1798created theller patch Per user site-packages and setup.py install --user patch 01/11/08 http://bugs.python.org/issue1799created tiran patch ctypes callback fails when called in Python with array argument 01/11/08 http://bugs.python.org/issue1800created kermode docs for os.symlink(src, dst) doesn't mention exceptions 01/11/08 CLOSED http://bugs.python.org/issue1809created dgardner AST compile() patch 01/11/08 http://bugs.python.org/issue1810created thomas.lee patch True division of integers could be more accurate 01/12/08 http://bugs.python.org/issue1811created marketdickinson doctest _load_testfile function -- newline handling seems incorr 01/12/08 http://bugs.python.org/issue1812created pdonis easy Codec lookup failing under turkish locale01/12/08 http://bugs.python.org/issue1813created arnimar Victor Stinner's GMP patch for longs 01/12/08 http://bugs.python.org/issue1814created tiran patch Distutils add ability to skip build [Feature Request]01/12/08 http://bugs.python.org/issue1815created Eloff sys.cmd_flags patch 01/12/08 CLOSED http://bugs.python.org/issue1816created tiran patch module-cgi: handling GET and POST together 01/13/08 http://bugs.python.org/issue1817created alef13 easy Add named tuple reader to CSV module 01/13/08 http://bugs.python.org/issue1818created rhettinger Speed hack for function calls with named parameters 01/14/08 http://bugs.python.org/issue1819created pitrou patch Enhance Object/structseq.c to match namedtuple and tuple api 01/14/08 http://bugs.python.org/issue1820created tiran easy configure.ac change for FreeBSD 01/14/08 CLOSED http://bugs.python.org/issue1821created asmodai email.mime.multipart.MIMEMultipart.is_multipart() returns false 01/14/08
Re: [Python-Dev] What to do for bytes in 2.6?
Christian Heimes wrote: > Ah, you like to keep it simple. The aliases are easily to implement. > Give me twenty minutes to implement it and write some unit tests. http://bugs.python.org/issue1865 ___ 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
