Re: [Python-Dev] bytes / unicode
On Sat, 26 Jun 2010 23:49:11 -0400
"P.J. Eby" wrote:
>
> Remember, bytes and strings already have to detect mixed-type
> operations.
Not in Python 3. They just raise a TypeError on bad
("mixed-type") arguments.
Regards
Antoine.
___
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] thoughts on the bytes/string discussion
Stefan Behnel wrote: Greg Ewing, 26.06.2010 09:58: Would there be any sanity in having an option to compile Python with UTF-8 as the internal string representation? It would break Py_UNICODE, because the internal size of a unicode character would no longer be fixed. It's not fixed anyway with the 2-char build -- some characters are represented using a pair of surrogates. -- Greg ___ 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] Adopt A Demo [was: Signs of neglect?]
Am 26.06.2010 00:38, schrieb Steve Holden: > I was pretty stunned when I tried this. Remember that the Tools > subdirectory is distributed with Windows, so this means we got through > almost two releases without anyone realizing that 2to3 does not appear > to have touched this code. > > Yes, I have: http://bugs.python.org/issue9083 > > When's 3.2 due out? The alpha stage is beginning next week; still enough time to fix the Tools and Demos. I can do some of the work, however, if I have to do it all, I'll just throw out the majority of that stuff. So -- if every dev "adopted" a Tool or Demo, that would be quite a manageable piece of work, and maybe a few demos can be brought up to scratch instead of be deleted. I'll go ahead and promise to care for the "Demo/classes" subdir. 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] #Python3 ! ? (was Python Library Support in 3.x)
Am 22.06.2010 01:01, schrieb Terry Reedy: > On 6/21/2010 3:59 PM, Steve Holden wrote: >> Terry Reedy wrote: >>> On 6/21/2010 8:33 AM, Nick Coghlan wrote: >>> P.S. (We're going to have a tough decision to make somewhere along the line where docs.python.org is concerned, too - when do we flick the switch and make a 3.x version of the docs the default? >>> >>> Easy. When 3.2 is released. When 2.7 is released, 3.2 becomes 'trunk'. >>> Trunk released always take over docs.python.org. To do otherwise would >>> be to say that 3.2 is not a real trunk release and not yet ready for >>> real use -- a major slam. >>> >>> Actually, I thought this was already discussed and decided ;-). >>> >> This also gives the 2.7 release it's day in the sun before relegation to >> maintenance status. > > Every new version (except 3.0 and 3.1) has gone to maintenance status > *and* becomes the featured release on docs.python.org the day it was > released. 2.7 would just spend less time as the featured release on > that page. I'm not sure 3.2 should take over in December just yet. (There's also docs3.python.org that always lands at the latest 3.x documentation). However, there will be enough time to discuss this when 3.2 is actually about to be released. 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] Adopt A Demo [was: Signs of neglect?]
On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl wrote: > So -- if every dev "adopted" a Tool or Demo, that would be quite a > manageable piece of work, and maybe a few demos can be brought up > to scratch instead of be deleted. > > I'll go ahead and promise to care for the "Demo/classes" subdir. Bagsy the Demo/parser subdirectory. Fixing up unparse.py looks like it could be fun. Mark ___ 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] thoughts on the bytes/string discussion
On 6/27/2010 5:48 AM, Greg Ewing wrote: Stefan Behnel wrote: Greg Ewing, 26.06.2010 09:58: Would there be any sanity in having an option to compile Python with UTF-8 as the internal string representation? It would break Py_UNICODE, because the internal size of a unicode character would no longer be fixed. It's not fixed anyway with the 2-char build -- some characters are represented using a pair of surrogates. But isn't this currently ignored everywhere in python's code? Eric. ___ 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 / unicode
P.J. Eby writes: > At 12:42 PM 6/26/2010 +0900, Stephen J. Turnbull wrote: > >What I'm saying here is that if bytes are the signal of validity, and > >the stdlib functions preserve validity, then it's better to have the > >stdlib functions object to unicode data as an argument. Compare the > >alternative: it returns a unicode object which might get passed around > >for a while before one of your functions receives it and identifies it > >as unvalidated data. > > I still don't follow, OK, I give up, since it was your use case that concerned me. I obviously misunderstood. Sorry for the confusion. Sign me, +1 on polymorphic functions in Tsukuba Japan > >In general this is a hard problem, though. Polymorphism, OK, one-way > >tainting OK, but in general combining related types is pretty > >arbitrary, and as in the encoded-bytes case, the result type often > >varies depending on expectations of callers, not the types of the > >data. > > But the caller can enforce those expectations by passing in arguments > whose types do what they want in such cases, as long as the string > literals used by the function don't get to override the relevant > parts of the string protocol(s). This simply isn't true for encoded bytes as proposed. For encoded text, the current encoding has no deterministic relationship to the desired encoding (at the level of generality of the stdlib; of course in specific applications it may be mandated by a standard or private convention). I will have to pass on your other user-defined string types. I've never tried to implement one. I only wanted to point out that a user-controllable tainted string type would be preferable to confounding "unicode" with "tainted". ___ 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] Adopt A Demo [was: Signs of neglect?]
On Sun, Jun 27, 2010 at 5:57 AM, Mark Dickinson wrote: > On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl wrote: >> So -- if every dev "adopted" a Tool or Demo, that would be quite a >> manageable piece of work, and maybe a few demos can be brought up >> to scratch instead of be deleted. >> >> I'll go ahead and promise to care for the "Demo/classes" subdir. > > Bagsy the Demo/parser subdirectory. Fixing up unparse.py looks like > it could be fun. I have a patch for pybench attached to a not so related issue at http://bugs.python.org/issue5180 . All it took was a 2to3 run and a one line change. Of course it need a review before it can go in, but I am surprised that something like pybench was not updated long time ago. Is it supposed to be single source? That would make sense given the nature of the tool. > > Mark > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gmail.com > ___ 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] Adopt A Demo [was: Signs of neglect?]
Alexander Belopolsky wrote: > On Sun, Jun 27, 2010 at 5:57 AM, Mark Dickinson wrote: >> On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl wrote: >>> So -- if every dev "adopted" a Tool or Demo, that would be quite a >>> manageable piece of work, and maybe a few demos can be brought up >>> to scratch instead of be deleted. >>> >>> I'll go ahead and promise to care for the "Demo/classes" subdir. >> >> Bagsy the Demo/parser subdirectory. Fixing up unparse.py looks like >> it could be fun. > > I have a patch for pybench attached to a not so related issue at > http://bugs.python.org/issue5180 . All it took was a 2to3 run and a > one line change. Of course it need a review before it can go in, but > I am surprised that something like pybench was not updated long time > ago. Is it supposed to be single source? Yes, the idea was to keep the number of changes to a minimum and to have the Python3 version work with Python 2.6, 2.7 and 3.x. Antoine worked on that, AFAIR. The Python2 version of pybench needs to work with more than just Python 2.6 and 2.7 to be able to compare performance of the various releases back to version 2.3. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 27 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK21 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 / unicode
At 03:53 PM 6/27/2010 +1000, Nick Coghlan wrote: We could talk about this even longer, but the most effective way forward is going to be a patch that improves the URL parsing situation. Certainly, it's the only practical solution for the immediate problems in 3.2. I only mentioned that I "hate the idea" because I'd be more comfortable if it was explicitly declared to be a temporary hack to work around the absence of a string coercion protocol, due to the moratorium on language changes. But, since the moratorium *is* in effect, I'll try to make this my last post on string protocols for a while... and maybe wait until I've looked at the code (str/bytes C implementations) in more detail and can make a more concrete proposal for what the protocol would be and how it would work. (Not to mention closer to the end of the moratorium.) There are a *very small* number of APIs where it is appropriate to be polymorphic This is only true if you focus exclusively on bytes vs. unicode, rather than the general issue that it's currently impractical to pass *any* sort of user-defined string type through code that you don't directly control (stdlib or third-party). The virtues of a separate poly_str type are that: 1. It can be simple and implemented in Python, dispatching to str or bytes as appropriate (probably in the strings module) 2. No chance of impacting the performance of the core interpreter (as builtins are not affected) Note that adding a string coercion protocol isn't going to change core performance for existing cases, since any place where the protocol would be invoked would be a code branch that either throws an error or *already* falls back to some other protocol (e.g. the buffer protocol). 3. Lower impact if it turns out to have been a bad idea How many protocols have been added that turned out to be bad ideas? The only ones that have been removed in 3.x, IIRC, are three-way compare, slice-specific operations, and __coerce__... and I'm going to miss __cmp__. ;-) However, IIUC, the reason these protocols were dropped isn't because they were "bad ideas". Rather, they're things that can be implemented in terms of a finer-grained protocol. i.e., if you want __cmp__ or __getslice__ or __coerce__, you can always implement them via a mixin that converts the newer fine-grained protocols into invocations of the older protocol. (As I plan to do for __cmp__ in the handful of places I use it.) At the moment, however, this isn't possible for multi-string operations outside of __add__/__radd__ and comparison -- the coercion rules are hard-wired and can't be overridden by user-defined types. ___ 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] pybench
On Sun, 27 Jun 2010 10:47:08 -0400 Alexander Belopolsky wrote: > > I have a patch for pybench attached to a not so related issue at > http://bugs.python.org/issue5180 . All it took was a 2to3 run and a > one line change. Of course it need a review before it can go in, but > I am surprised that something like pybench was not updated long time > ago. Why do you say that? pybench works fine under Python 3 (the py3k branch version of pybench, that is). The patch doesn't look necessary to me. ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On 6/27/2010 5:44 AM, Georg Brandl wrote: Am 22.06.2010 01:01, schrieb Terry Reedy: On 6/21/2010 3:59 PM, Steve Holden wrote: Terry Reedy wrote: On 6/21/2010 8:33 AM, Nick Coghlan wrote: P.S. (We're going to have a tough decision to make somewhere along the line where docs.python.org is concerned, too - when do we flick the switch and make a 3.x version of the docs the default? Easy. When 3.2 is released. When 2.7 is released, 3.2 becomes 'trunk'. Trunk released always take over docs.python.org. To do otherwise would be to say that 3.2 is not a real trunk release and not yet ready for real use -- a major slam. Actually, I thought this was already discussed and decided ;-). This also gives the 2.7 release it's day in the sun before relegation to maintenance status. Every new version (except 3.0 and 3.1) has gone to maintenance status *and* becomes the featured release on docs.python.org the day it was released. 2.7 would just spend less time as the featured release on that page. I'm not sure 3.2 should take over in December just yet. (There's also docs3.python.org that always lands at the latest 3.x documentation). However, there will be enough time to discuss this when 3.2 is actually about to be released. Sure. Since I expect that the argument for treating 3.2 as a regular production-use-ready release will be stronger then than now, I agree on differing discussion. -- Terry Jan Reedy ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Am 21.06.2010 17:13, schrieb Stephan Richter: > On Monday, June 21, 2010, Nick Coghlan wrote: >> A decent listing of major packages that already support Python 3 would >> be very handy for the new Python2orPython3 page I created on the wiki, >> and easier to keep up-to-date. (the old Early2to3Migrations page >> didn't look particularly up to date, but hopefully we can keep the new >> list in a happier state). > > I really just want to be able to go to PyPI, Click on "Browse packages" and > then select "Python 3" (it can currently be accomplished by clicking "Python" > and then "3"). Or you can use the link "Python 3 packages" on PyPI's main menu. 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] what environment variable should contain compiler warning suppression flags?
Brett Cannon wrote: On Sat, Jun 26, 2010 at 16:37, M.-A. Lemburg wrote: Brett Cannon wrote: On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote: [SKIP] Since no one objected I swapped the order in r82259. In case anyone else uses clang to compile Python, this means that -Wno-unused-value will now work to silence the warning about unused return values that is caused by some macros. Probably using -Wno-empty-body is also good to avoid all the warnings triggered by the UCS4 macros in cjkcodecs. Right now you cannot change order of CFLAGS and OPT I think you need to come up with a different solution and revert the change... OPT has historically been the only variable to use for adjusting the Python C compiler settings. Just found the relevant section in the README. As the name implies this was usually used to adjust the optimizer settings, including raising the optimization level from the default or disabling it. It meant optional to me, not optimization. I hate abbreviations sometimes. With your change CFLAGS will always override OPT and thus any optimization definitions made in OPT will no longer have an effect. That was the point; OPT defines defaults through configure.in and I simply wanted to add to those instead of having OPT completely overwritten by me. Now if you confirm that (see configure.in ) : # Optimization messes up debuggers, so turn it off for # debug builds. OPT="-g -O0 -Wall $STRICT_PROTO" is not issue for py3k then left you commit as is (Note that Mark point this). But if optimization "messes up debuggers" you may revert change. I know that is difficult to reach consensus on compiler/preprocessor flags for python build process. Next is a shot list with issues about this: - "Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1" : http://bugs.python.org/issue1628484 (committed/rejected) - "Python does not honor "CFLAGS" environment variable" : http://bugs.python.org/issue1453 (wont fix) - "configure: allow user-provided CFLAGS to override AC_PROG_CC defaults" : http://bugs.python.org/issue8211 (fixed) This is still open "configure doesn't set up CFLAGS properly" ( http://bugs.python.org/issue1104249 ) - must be closed as fixed. Note that CFLAGS defines -O2 on many platforms. So then wouldn't that mean they want that to be the optimization level? Or is the historical reason that default exists is so that some default exists but to expect the application to override as desired? In your particular case, you should try setting OPT to "... -Wno-unused-value ..." (ie. replace -Wall with your setting). So what is CFLAGS for then? ``configure -h`` says it's for "C compiler flags"; that's extremely ambiguous. And it doesn't help that OPT is not mentioned by ``configure -h`` as that is what I have always gone by to know what flags are available for compilation. -Brett If you like to see some flags the could you look into http://bugs.python.org/issue3718 how to define an option to be visible by configure --help. In addition AC_ARG_VAR will allow environment variable to be cached for subsequent run of config.status otherwise you must specify only on configure command line. About all XXflags variables if is good configure script to be simplified to use only CPPFLAGS and CFLAGS to minimize configuration troubles and other build falures. A good sample if configure set preprocessor/compiler flags other then CPPFLAGS/CFLAGS is this issue "OSX: duplicate -arch flags in CFLAGS breaks sysconfig" ( http://bugs.python.org/issue8607 ) Roumen ___ 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 environment variable should contain compiler warning suppression flags?
On Sun, Jun 27, 2010 at 12:37 AM, M.-A. Lemburg wrote: > Brett Cannon wrote: >> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote: >>> I finally realized why clang has not been silencing its warnings about >>> unused return values: I have -Wno-unused-value set in CFLAGS which >>> comes before OPT (which defines -Wall) as set in PY_CFLAGS in >>> Makefile.pre.in. >>> >>> I could obviously set OPT in my environment, but that would override >>> the default OPT settings Python uses. I could put it in EXTRA_CFLAGS, >>> but the README says that's for stuff that tweak binary compatibility. >>> >>> So basically what I am asking is what environment variable should I >>> use? If CFLAGS is correct then does anyone have any issues if I change >>> the order of things for PY_CFLAGS in the Makefile so that CFLAGS comes >>> after OPT? >>> >> >> Since no one objected I swapped the order in r82259. In case anyone >> else uses clang to compile Python, this means that -Wno-unused-value >> will now work to silence the warning about unused return values that >> is caused by some macros. Probably using -Wno-empty-body is also good >> to avoid all the warnings triggered by the UCS4 macros in cjkcodecs. > > I think you need to come up with a different solution and revert > the change... Agreed; this needs more thought. For one thing, Brett's change has the result that --with-pydebug builds end up being built with -O2 instead of -O0, which can make debugging (e.g., with gdb) somewhat awkward. Mark ___ 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 environment variable should contain compiler warning suppression flags?
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote: > AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based > systems > (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842). > If Python's configure.in sets an otherwise-empty CFLAGS to -g before > calling AC_PROG_CC, AC_PROG_CC won't change it. Or we could just > preserve the users CFLAGS setting across AC_PROG_CC regardless of > whether it's set, to let the user set CFLAGS on the configure line > without stomping any defaults. I think saving and restoring CFLAGS across AC_PROG_CC was attempted in http://bugs.python.org/issue8211 . It turned out that it broke OS X universal builds. I'm not sure I understand the importance of allowing AC_PROG_CC to set CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can someone give an example of why this is necessary? Mark ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Sure. Since I expect that the argument for treating 3.2 as a regular production-use-ready release will be stronger then than now, I agree on differing discussion. I meant 'deferring' -- Terry Jan Reedy ___ 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 environment variable should contain compiler warning suppression flags?
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: > On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote: >> AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based >> systems >> (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842). >> If Python's configure.in sets an otherwise-empty CFLAGS to -g before >> calling AC_PROG_CC, AC_PROG_CC won't change it. Or we could just >> preserve the users CFLAGS setting across AC_PROG_CC regardless of >> whether it's set, to let the user set CFLAGS on the configure line >> without stomping any defaults. > > I think saving and restoring CFLAGS across AC_PROG_CC was attempted in > http://bugs.python.org/issue8211 . It turned out that it broke OS X > universal builds. Thanks for the link to the issue. http://bugs.python.org/issue8366 says Ronald Oussoren fixed the universal builds without reverting the CFLAGS propagation. > I'm not sure I understand the importance of allowing AC_PROG_CC to set > CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can > someone give an example of why this is necessary? Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds other flags as well (it currently doesn't, but that may well change in future versions of autoconf)." That seems a little weak to constrain fixing actual problems today. If it ever adds more arguments, we'll need to inspect them anyway to see if they're more like -g or -O2 (wanted or harmful). Jeffrey ___ 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 environment variable should contain compiler warning suppression flags?
On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote: > On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: >> On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote: >>> AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based >>> systems >>> (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842). >>> If Python's configure.in sets an otherwise-empty CFLAGS to -g before >>> calling AC_PROG_CC, AC_PROG_CC won't change it. Or we could just >>> preserve the users CFLAGS setting across AC_PROG_CC regardless of >>> whether it's set, to let the user set CFLAGS on the configure line >>> without stomping any defaults. >> >> I think saving and restoring CFLAGS across AC_PROG_CC was attempted in >> http://bugs.python.org/issue8211 . It turned out that it broke OS X >> universal builds. > > Thanks for the link to the issue. http://bugs.python.org/issue8366 > says Ronald Oussoren fixed the universal builds without reverting the > CFLAGS propagation. > >> I'm not sure I understand the importance of allowing AC_PROG_CC to set >> CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can >> someone give an example of why this is necessary? > > Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds > other flags as well (it currently doesn't, but that may well change in > future versions of autoconf)." That seems a little weak to constrain > fixing actual problems today. If it ever adds more arguments, we'll > need to inspect them anyway to see if they're more like -g or -O2 > (wanted or harmful). > I went ahead and reverted the change, but it does seem like the build environment could use a cleanup. ___ 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 environment variable should contain compiler warning suppression flags?
On Sun, Jun 27, 2010 at 9:37 PM, Jeffrey Yasskin wrote: > On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote: >> I think saving and restoring CFLAGS across AC_PROG_CC was attempted in >> http://bugs.python.org/issue8211 . It turned out that it broke OS X >> universal builds. > > Thanks for the link to the issue. http://bugs.python.org/issue8366 > says Ronald Oussoren fixed the universal builds without reverting the > CFLAGS propagation. Yes, you're right (of course). Thanks. Looking at the current configure.in, CFLAGS *does* get saved and restored across the AC_PROG_CC call if it's non-empty; I'm not sure whether this actually (currently) has any effect, since as I understand the documentation CFLAGS won't be touched by AC_PROG_CC if it's already set. >> I'm not sure I understand the importance of allowing AC_PROG_CC to set >> CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC); can >> someone give an example of why this is necessary? > > Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds > other flags as well (it currently doesn't, but that may well change in > future versions of autoconf)." That seems a little weak to constrain > fixing actual problems today. If it ever adds more arguments, we'll > need to inspect them anyway to see if they're more like -g or -O2 > (wanted or harmful). Okay; thanks for the explanation. Mark ___ 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] thoughts on the bytes/string discussion
Eric Smith wrote: But isn't this currently ignored everywhere in python's code? It's true that code using a utf-8 build would have to be aware of the fact much more often. But I'm thinking of applications that would otherwise want to keep all their strings encoded to save memory. If they do that, they also need to deal with sequence items not corresponding to characters. If they can handle that, they may be able to handle utf-8 just as well. -- Greg ___ 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 / unicode
I've been watching this discussion with intense interest, but have been so lagged in following the thread that I haven't replied. I got caught up today On Sun, 27 Jun 2010 15:53:59 +1000, Nick Coghlan wrote: > The difference is that we have three classes of algorithm here: > - those that work only on octet sequences > - those that work only on character sequences > - those that can work on either > > Python 2 lumped all 3 classes of algorithm together through the > multi-purpose 8-bit str type. The unicode type provided some scope to > separate out the second category, but the divisions were rather > blurry. > > Python 3 forces the first two to be separated by using either octets > (bytes/bytearray) or characters (str). There are a *very small* number > of APIs where it is appropriate to be polymorphic, but this is > currently difficult due to the need to supply literals of the > appropriate type for the objects being operated on. > > This isn't ever going to happen automagically due to the need to > explicitly provide two literals (one for octet sequences, one for > character sequences). In email6 I'm currently handling this by putting the algorithm on a base class and the literals on 'Bytes...' and 'String...' subclasses as class variables. Slightly ugly, but it works. The current design also speaks to an earlier point someone made about the fact that we are really dealing with more complex, and domain specific, data, not simply "byte strings". A "BytesMessage" contains lots of structured encoding information as well as the possibility of 'garbage' bytes. A StringMessage contains text and data decoded into objects (ex: an image object), possibly with some PEP 383 surrogates included (haven't quite figured that part out yet). So, a BytesMessage object isn't just a byte string, it's a load of structured data that requires the associated algorithms to convert into meaningful text and objects. Going the other way, the decisions made about character encodings need to be encoded into the structured bytes representation that could ultimately go out on the wire. I suspect that the same thing needs to be done for URIs/IRIs, and html/MIME and the corresponding text and objects. It is my hope that the email6 work will lay a firm foundation for the latter, but URI/IRI is a whole different protocol that I'm glad I don't have to deal with :) > The virtues of a separate poly_str type are that: Having such a poly_str type would probably make my life easier. I also would like just vent a little frustration at having to use single-character-slice notation when I want to index a character in a string in my algorithms -- R. David Murray www.bitdance.com ___ 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] thoughts on the bytes/string discussion
On Fri, 25 Jun 2010 15:40:52 -0700, Bill Janssen wrote: > Guido van Rossum wrote: > > So you're really just worried about space consumption. I'd like to see > > a lot of hard memory profiling data before I got overly worried about > > that. > > While I've seen some big Web pages, I think the email folks, who often > have to process messages with attachments measuring in the tens of > megabytes, have the stronger problems here, and I think speed may be > more important than memory. I've built both a Web server and an IMAP > server in Python, and the IMAP server is where the issues of storage > management really prevail. If you have to convert a 20 MB encoded > string into a Unicode string just to look at the headers as strings, you > have issues. (The Python email package doesn't do that, by the way.) Unfortunately in the current Python3 email package (email5), this is no longer true. You have to decode everything *first* in order to pass it through email (which presents a few problems when dealing with 8bit data, as has been mentioned here before). eamil6 intends to fix this, and once again allow you to decode to text only the bits you actually need to access and manipulate. -- R. David Murray www.bitdance.com ___ 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] email package status in 3.X
On Fri, 18 Jun 2010 18:52:45 -, [email protected] wrote: > What I'm suggesting is that extreme caution be exercised from > this point forward with all things 3.X-related. Whether you > wish to accept this or not, 3.X has a negative image to many. > This suggestion specifically includes not abandoning current > 3.X email package users as a case in point. Ripping the rug > out from new 3.X users after they took the time to port seems > like it may be just enough to tip the scales altogether. Catching up on my python-dev email, I just want to clarify this with respect to email. (1) I suspect that the new API will be enough of a carrot that they won't mind converting to it, BUT, (2) the plan is to provide a compatibility API that will fully support the current Python3 email5 API (but with fewer bugs in areas such as header folding and unfolding). -- R. David Murray www.bitdance.com ___ 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] [ANN]: "newthreading" - an approach to simplified thread usage, and a path to getting rid of the GIL
fyi - newthreading has been picked up by lwn. http://lwn.net/Articles/393822/#Comments ___ 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
