[Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
Hi, As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct. I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90. With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected. Looking forward to hearing others' opinions, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 0420: Extent of implementation? Specifically Python 2?
On 06/19/2015 08:21 AM, triccare triccare wrote: And, more generally, is there a way to know the extent of implementation of any particular PEP? By default, no new features are going into the 2.7 line. If something does, it will be mentioned explicitly in the PEP. See PEP 466 [1] and 476 [2] as examples. -- ~Ethan~ [1] https://www.python.org/dev/peps/pep-0466/ [2] https://www.python.org/dev/peps/pep-0476/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
Zachary Ware wrote: With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. I'm selfishly -0, since this won't benefit me and will give me more work (I don't develop 2.7 other than to build the releases, so this will just cause me to mess with my build machine). But since other people are doing most of the work I'm not going to try and block it. I don't see any real need to emit scary warnings about compiler compatibility - a simple warning like in 3.5 for old compilers is fine. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. It may have a workaround, but it also could be a serious blocking issue for those who can't install another version. Especially since there's no benefit to the resulting builds. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. Agreed, just replace them. PCBuild is messy enough with the output files in there (I'd avoid moving them - plenty of the stdlib and test suite expects them to be there), we don't need duplicate project files. Cheers, Steve I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected. Looking forward to hearing others' opinions, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
I'd like to backport those new project files to 2.7, Would this change anything about how extensions are built? There is now the ms compiler for 2.7 would that work? Or only in concert with VS2010 express? -CHB and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90. With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected. Looking forward to hearing others' opinions, -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 490: Chain exceptions at C level
On 23 Jun 2015 04:12, Ethan Furman et...@stoneleaf.us wrote: -1 on auto-chaining. +1 on chaining helper functions so it's dirt-simple. Chiming in again since I wasn't clear on this aspect last time: I'd also be +1 on parallel APIs that handle the chaining. Since the auto-chaining idea seems largely unpopular, that suggests to me that a parallel set of APIs would be the most readily accepted way forward. I nominate a *Chained suffix as my suggested colour for the bikeshed :) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
Updating the build system to better handle changes in underlying platforms is one of the standard exemptions arising from Python 2.7's long term support status, so if this change makes things easier for contributors on Windows, +1 from me. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On Mon, Jun 22, 2015 at 3:03 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 June 2015 at 08:46, Ivan Levkivskyi levkivs...@gmail.com wrote:
On 21 June 2015 at 22:05, Guido van Rossum gu...@python.org wrote:
On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi levkivs...@gmail.com
wrote:
It is still not clear whether Guido's comment still stands for not
raising an UnboundLocalError in class definitions but using globals
instead.
Can you phrase this in the form of an example, showing what it currently
does and what you think it should do, instead?
Here is an example:
x = xtop
y = ytop
def func():
x = xlocal
y = ylocal
class C:
print(x)
print(y)
y = 1
func()
prints
xlocal
ytop
Intuitively, one might think that it should raise UnboundLocalError or
print
ylocal instead of ytop.
This question was discussed 13 years ago and then you said that this
lookup
in globals
is an intentional behavior.
This behavior is not documented, and I started an issue on bug tracker
about documenting it.
Then, Eric proposed to ask you again, whether this is still an
intentional
behavior.
Diving into some bytecode details:
In particular, the bytecode for C is:
dis.dis(func.__code__.co_consts[3])
6 0 LOAD_NAME0 (__name__)
3 STORE_NAME 1 (__module__)
6 LOAD_CONST 0 ('func.locals.C')
9 STORE_NAME 2 (__qualname__)
7 12 LOAD_NAME3 (print)
15 LOAD_CLASSDEREF 0 (x)
18 CALL_FUNCTION1 (1 positional, 0 keyword pair)
21 POP_TOP
8 22 LOAD_NAME3 (print)
25 LOAD_NAME4 (y)
28 CALL_FUNCTION1 (1 positional, 0 keyword pair)
31 POP_TOP
9 32 LOAD_CONST 1 (1)
35 STORE_NAME 4 (y)
38 LOAD_CONST 2 (None)
41 RETURN_VALUE
We added LOAD_CLASSDEREF
(https://docs.python.org/3/library/dis.html#opcode-LOAD_CLASSDEREF) a
while back to account for the fact that __prepare__ may inject locals
into a class body that the compiler doesn't know about. Unlike
LOAD_DEREF, LOAD_CLASSDEREF checks the locals before it checks the
closure cell.
However, neither LOAD_CLASSDEREF *nor* LOAD_DEREF is used for names
that are *assigned* in the class body - those get flagged as local
variables, so we end up emitting LOAD_NAME for them, and hence ignore
any nonlocal variables with that name. If a module global or builtin
exists, we'll find that, otherwise we'll throw NameError.
With nested_scopes having been the default since 2.2, and accounting
for the fact that folks *do* write code like name = name at class
scope and expect it to do the right thing, it seems reasonable to me
to just make this work properly, rather than having to explain why it
doesn't work as one might expected based on the behaviour of module
level class definitions and other references to nonlocal variables
from a class body.
But what *is* the correct behavior? I suspect people's intuitions differ.
If you think of this as similar to function scopes you're likely to be
wrong.
Also, since classes inside functions are commonly used in unit tests (at
least mine :-), I worry that *any* changes in this behavior might break
working code (no matter how much that working could be considered an
accident, it's still going to be a bear to debug if this happens to you).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 490: Chain exceptions at C level
-1 on auto-chaining. +1 on chaining helper functions so it's dirt-simple. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On 23 June 2015 at 11:45, Zachary Ware zachary.ware+py...@gmail.com wrote: On Mon, Jun 22, 2015 at 6:29 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: I'd like to backport those new project files to 2.7, Would this change anything about how extensions are built? There is now the ms compiler for 2.7 would that work? Or only in concert with VS2010 express? It should have absolutely no impact on building extensions. If it does, that's a bug to be fixed. Regular users of Python on Windows (those who don't build their own) should have no idea that anything has changed at all. I'd suggest explicitly reaching out to the Stackless folks to get their feedback. As I believe the switched to a newer compiler and VC runtime for Windows a while back, I suspect it will make their lives easier rather than harder, but it's still worth asking for their input. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 6:29 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: I'd like to backport those new project files to 2.7, Would this change anything about how extensions are built? There is now the ms compiler for 2.7 would that work? Or only in concert with VS2010 express? It should have absolutely no impact on building extensions. If it does, that's a bug to be fixed. Regular users of Python on Windows (those who don't build their own) should have no idea that anything has changed at all. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speed.python.org (was: 2.7 is here until 2020, please don't call it a waste.)
On Thu, Jun 4, 2015 at 10:51 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Thu, Jun 4, 2015 at 4:32 PM, R. David Murray rdmur...@bitdance.com wrote: OK, so what you are saying is that speed.python.org will run a buildbot slave so that when a change is committed to cPython, a speed run will be triggered? Is the runner a normal buildbot slave, or something custom? In the normal case the master controls what the slave runs...but regardless, you'll need to let us know how the slave invocation needs to be configured on the master. Ideally nightly (benchmarks take a while). The setup for pypy looks like this: https://bitbucket.org/pypy/buildbot/src/5fa1f1a4990f842dfbee416c4c2e2f6f75d451c4/bot2/pypybuildbot/builds.py?at=default#cl-734 so fairly easy. This already generates a json file that you can plot. We can setup an upload automatically too. I've been looking at what it will take to set up the buildmaster for this, and it looks like it's just a matter of checking out the benchmarks, building Python, testing it, and running the benchmarks. There is the question of which benchmark repo to use: https://bitbucket.org/pypy/benchmarks or https://hg.python.org/benchmarks; ideally, we should use hg.python.org/benchmarks for CPython benchmarks, but it looks like pypy/benchmarks has the necessary runner, so I suppose we'll be using it for now. Is there interest from both sides to merge those repositories? The big question for the buildmaster is what options to pass to the benchmark runner. I suppose most of them should match the CPythonBenchmark BuildFactory from the PyPy buildbot master configuration, but otherwise I'm not sure. The other big question is where the benchmarks will be run. The speed.python.org page makes it sound like there's a box intended for that purpose (the one running the speed.python.org page?); can anyone with access to it contact me to get the build slave set up? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On 22 June 2015 at 17:13, Guido van Rossum gu...@python.org wrote: But what *is* the correct behavior? I suspect people's intuitions differ. If you think of this as similar to function scopes you're likely to be wrong. For me, there's a correct answer for *new* users based on the combination of: 1. For module level class definitions, if you look up a name before binding it locally, it's looked up the same way it would be if you never bound it locally at all 2. For function level class definitions, If the name isn't bound locally in the class body, nonlocals are visible as if the class body was running in the scope of the function defining the class If folks never experienced Python as it existed prior to 2.2, the current behaviour isn't likely to be at all intuitive to them (I barely make it into that category myself - prior to adopting 2.2.2 for DSP testing in 2002 or so, my sole experience with Python 1.5.2 was a single university level networking class*) Also, since classes inside functions are commonly used in unit tests (at least mine :-), I worry that *any* changes in this behavior might break working code (no matter how much that working could be considered an accident, it's still going to be a bear to debug if this happens to you). Agreed - I think any change here would need to go through a deprecation period where we warned about cases where LOAD_NAME would be changed to LOAD_CLASSDEREF and there was a nonlocal defined with that name. Since it's trivial easy to workaround by renaming a local variable to use a name that differs from the nested class attribute, I'd also be entirely happy with leaving the current behaviour as an obscure quirk - I'm only +0 on changing it, and also +0 on declaring it not worth the hassle of changing. Cheers, Nick. P.S. *Two fun facts about that class (this was in the late 90's): a) the lecturer *required* us to use Python as he assumed there'd be very few people that already knew it, so we'd be starting off on a more level playing field; and b) I asked if I could use Java instead, since I already knew that at the time (he said no, and Python really *was* very easy to pick up for the assignments we needed to do. It made it up again an easy choice several years later) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 10:37 PM, Nick Coghlan ncogh...@gmail.com wrote: I'd suggest explicitly reaching out to the Stackless folks to get their feedback. As I believe the switched to a newer compiler and VC runtime for Windows a while back, I suspect it will make their lives easier rather than harder, but it's still worth asking for their input. From a glance at the stackless repo, it looks like it still uses VS2008's project files (which pretty much means using MSVC 9), but I could have easily missed something. Christian, what say you? Would having the project files from 3.5 backported to 2.7 (but still using MSVC 9) be positive, negative, or indifferent for Stackless? -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do people like the early 3.5 branch?
On 17 June 2015 at 09:26, Larry Hastings la...@hastings.org wrote: A quick look through the checkin logs suggests that there's literally nothing happening in 3.6 right now. All the checkins are merges. Is anyone expecting to do work in 3.6 soon? Or did the early branch just create a bunch of make-work for everybody? A bit of a belated reply here, but my main observations are: 1. I still like the general idea 2. In the absence of ongoing integration testing against major third party projects, I think the second beta might be a better branch point than the first one PEPs 489 (extension module loading) and 492 (async/await) are my main reason for thinking that: * For PEP 489, which represented a major refactoring of an existing system, the first beta revealed a critical gap in the regression test suite (hence the brown-paper-bag early beta 2 release) * For PEP 492, which represented the introduction of a major new system, the first beta revealed some non-trivial interoperability issues that hadn't been considered in the original design On the other hand, that qualifier on the second observation is a fairly important one :) I've been thinking more about what a gated third party continuous integration repo might look like, and I'm beginning to think if we structured it appropriately, the idea might be simpler than I previously thought. The essential components seem to be: 1. Listening to and/or regularly polling the BuildBot master to check for versions that pass the regression test suite on the stable Buildbot fleet (I'm not sure what BuildBot's notification options are, but cron is always available as a fallback option) 2. Pull those revisions into a local repo that's accessible read-only over the web 3. Tag the specific revision that passed (this keeps track of which revisions are known to pass the regression test suite, vs those that only came in as dependencies of passing revisions) 4. Ideally, publish a notification via an asynchronous notification system (e.g. fedmsg) that other CI systems can consume as a trigger for their own testing It's not at the top of my todo list right now, but if nobody beats me to it I'll try to see what I can set up in Kallithea some time in the next few months :) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7
On Mon, Jun 22, 2015 at 5:20 PM, Steve Dower steve.do...@microsoft.com wrote: Zachary Ware wrote: With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. I'm selfishly -0, since this won't benefit me and will give me more work (I don't develop 2.7 other than to build the releases, so this will just cause me to mess with my build machine). But since other people are doing most of the work I'm not going to try and block it. I will be making sure that the files in PC\VS9.0 do still work properly; I could also try to adjust paths in Tools\msi such that you would only need to use PC\VS9.0 instead of PCbuild. I have yet to successfully build an MSI for any Python release, though, so I can't make any promises about that working. I don't see any real need to emit scary warnings about compiler compatibility - a simple warning like in 3.5 for old compilers is fine. That's the one I was talking about, actually :). Describing it as a big scary warning was probably a bit much. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. It may have a workaround, but it also could be a serious blocking issue for those who can't install another version. Especially since there's no benefit to the resulting builds. The easiest workaround would be to use the project files in PC\VS9.0. It might work to install only whatever gets you a new-enough MSBuild, but I haven't tested that at all and thus don't know. I will tell you that it works to build the backported pcbuild.proj with \Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe, invoked from a clean environment on a machine with VS 2008, 2010, 2013, and 2015RC installed, though. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. Agreed, just replace them. PCBuild is messy enough with the output files in there (I'd avoid moving them - plenty of the stdlib and test suite expects them to be there), we don't need duplicate project files. That probably explains a few of the failures I'm still seeing that I hadn't dug into yet. -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 8.0 and 3.5
On Thu Jun 18 20:33:13 CEST 2015, Larry Hastings asked: On 06/18/2015 11:27 AM, Terry Reedy wrote: Unicode 8.0 was just released. Can we have unicodedata updated to match in 3.5? What does this entail? Data changes, code changes, both? Note that the unicode 7 changes also need to be considered, because python 3.4 used unicode 6.3. There are some changes to the recommendations on what to use in identifiers. Python doesn't follow precisely the previous rules, but it would be good to ensure that any newly allowed characters are intentional -- particularly for the newly defined characters. My gut feel is that it would have been fine during beta, but for the 3rd RC I am not so sure. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
