[Python-Dev] Should vars() return modifiable dict?
For objects with __dict__ vars() returns modifiable dict:
>>> class A():
... pass
...
>>> a = A()
>>> a.x = 42
>>> vars(a)
{'x': 42}
>>> vars(a)['x'] = 43
>>> vars(a)['y'] = 44
>>> a.x, a.y, vars(a)
(43, 44, {'y': 44, 'x': 43})
For globals vars() returns modifiable dict:
>>> x = 42
>>> vars()['x']
42
>>> vars()['x'] = 43
>>> vars()['y'] = 44
>>> vars()['x'], vars()['y']
(43, 44)
For locals vars() returns... hmm, partially modifiable dict:
>>> def f():
... x = 42
... print(vars())
... vars()['x'] = 43
... vars()['y'] = 44
... print(x, vars())
...
>>> f()
{'x': 42}
42 {'y': 44, 'x': 42}
Should behavior of vars() be corrected for locals?
Should vars() for objects with __slots__ [1] returns modifiable or
non-modifiable dict?
[1] http://bugs.python.org/issue13290
___
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] Proposed schedule for Python 3.4
Howdy howdy. Unless someone has a better idea, I'm the release manager for Python 3.4. I've roughed out a release schedule, assuming a 16-month period between 3.3 and 3.4. It works out to having 3.4 ship about seven weeks before the PyCon 2014 core dev sprint, so even if we slip some we should still have a fresh 3.5 "default" branch open for some hacking. Here are the dates, note that they're all Saturdays: - 3.4.0 alpha 1: August 3, 2013 - 3.4.0 alpha 2: August 31, 2013 - 3.4.0 alpha 3: September 28, 2013 - 3.4.0 alpha 4: October 19, 2013 - 3.4.0 beta 1: November 23, 2013 (Beta 1 is also "feature freeze"--no new features beyond this point.) - 3.4.0 beta 2: January 4, 2014 - 3.4.0 candidate 1: January 18, 2014 - 3.4.0 candidate 2: February 1, 2014 - 3.4.0 final: February 22, 2014 I welcome your feedback--without any further input I'll go ahead and post this as a PEP in a week or so. Happy hacking, //arry/ ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 4:57 PM, Larry Hastings wrote: > > Howdy howdy. Unless someone has a better idea, I'm the release manager for > Python 3.4. I've roughed out a release schedule, assuming a 16-month period > between 3.3 and 3.4. It works out to having 3.4 ship about seven weeks > before the PyCon 2014 core dev sprint, so even if we slip some we should > still have a fresh 3.5 "default" branch open for some hacking. > > Here are the dates, note that they're all Saturdays: > > - 3.4.0 alpha 1: August 3, 2013 Looks pretty good to me, but I'd still like to experiment with bringing this one up a few months (say to April, a few weeks after PyCon US 2013). I'm sure we can land enough interesting features between now and then for people to be willing to tinker with it and give us feedback :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed schedule for Python 3.4
> I've roughed out a release schedule Is there a rough list of changes for 3.4 written down somewhere, or is that only to be inferred based on PEPs whose Python-Version header reads "3.4"? How confident are you that the schedule you've proposed gives enough time for proposed changes to be implemented and to stablize? 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] Proposed schedule for Python 3.4
On 10/03/2012 01:40 PM, Nick Coghlan wrote: On Wed, Oct 3, 2012 at 4:57 PM, Larry Hastings wrote: - 3.4.0 alpha 1: August 3, 2013 Looks pretty good to me, but I'd still like to experiment with bringing this one up a few months (say to April, a few weeks after PyCon US 2013). I'm sure we can land enough interesting features between now and then for people to be willing to tinker with it and give us feedback :) I don't agree. It's my understanding that the alphas are largely ignored, and having them earlier would hardly make them more relevant. I'm not saying "no"--but I'd definitely want to see more people than just you clamoring for the early alphas before I agree to anything. //arry/ ___ 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] Proposed schedule for Python 3.4
On 10/03/2012 01:45 PM, Skip Montanaro wrote: Is there a rough list of changes for 3.4 written down somewhere, or is that only to be inferred based on PEPs whose Python-Version header reads "3.4"? How confident are you that the schedule you've proposed gives enough time for proposed changes to be implemented and to stablize? Here's a short list of proposed changes for 3.4--basically all the stuff that didn't make it in to 3.3: Candidate PEPs: * PEP 395: Qualified Names for Modules * PEP 3143: Standard daemon process library * PEP 3154: Pickle protocol version 4 Other proposed large-scale changes: * Breaking out standard library and docs in separate repos * Addition of the "packaging" module, deprecating "distutils" * Addition of the "regex" module * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending) As for the rest of it, my understanding was that there is no longer any great plan written in the stars for Python releases. Python releases are comprised of whatever features people propose, implement, and are willing to support, that they can get done in time for the beta cutoff. From that perspective, the schedule drives the features more than the other-way around. The schedule proposes six weeks between feature-freeze and release. If that isn't enough we'll slip a little. But given that we have little idea what features will make it in to 3.4, it's hard to say for certain whether or not that's enough time. At this point all I can do is propose a schedule and hope for the best. Here's hoping, //arry/ ___ 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] Proposed schedule for Python 3.4
On 10/03/2012 01:54 PM, Larry Hastings wrote: On 10/03/2012 01:45 PM, Skip Montanaro wrote: Is there a rough list of changes for 3.4 written down somewhere, or is that only to be inferred based on PEPs whose Python-Version header reads "3.4"? How confident are you that the schedule you've proposed gives enough time for proposed changes to be implemented and to stablize? Here's a short list of proposed changes for 3.4--basically all the stuff that didn't make it in to 3.3: Candidate PEPs: * PEP 395: Qualified Names for Modules * PEP 3143: Standard daemon process library * PEP 3154: Pickle protocol version 4 Other proposed large-scale changes: * Breaking out standard library and docs in separate repos * Addition of the "packaging" module, deprecating "distutils" * Addition of the "regex" module * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending) As for the rest of it, my understanding was that there is no longer any great plan written in the stars for Python releases. Python releases are comprised of whatever features people propose, implement, and are willing to support, that they can get done in time for the beta cutoff. From that perspective, the schedule drives the features more than the other-way around. The schedule proposes six weeks between feature-freeze and release. Looks more like 3 months, which is fine. Georg ___ 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] Proposed schedule for Python 3.4
On Oct 03, 2012, at 06:45 AM, Skip Montanaro wrote: >Is there a rough list of changes for 3.4 written down somewhere Let the wild rumpus begin! -Barry ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote: > I don't agree. It's my understanding that the alphas are largely ignored, > and having them earlier would hardly make them more relevant. I would appreciate it you stopped promoting this myth. Each step in the release process widens the pool of people providing feedback. Some are providing feedback (and patches!) right the way through by building their own copy of Python from source, a few start poking around with the first alpha, more wait for feature freeze, we get a whole slew of people that wait until the release candidates come out, and then we get even more that don't check for backwards incompatible changes until after the final release (so they have to wait until the x.y.1 release before they can upgrade). Yes, the pool is substantially smaller in the early phases, but phrases like "largely ignored" do a grave disservice to our alpha testers that provide early feedback when we have plenty of time to fix problems, rather than leaving their checks to the last minute and forcing us to choose between delaying the release and shipping with known defects. > I'm not > saying "no"--but I'd definitely want to see more people than just you > clamoring for the early alphas before I agree to anything. Python 3.4 will almost certainly include significant changes to main module and sys.path initialisation as well as the way import failures are reported at the command line (and perhaps in the interactive interpreter), along with some adjustments to the Unicode handling feature set and the disassembly support. I *can't* effectively trial those changes on PyPI (except perhaps some of the disassembly changes), and I don't have the resources to create and distribute Windows and Mac OS X installers on my own. That means, before the release of 3.4a1, any feedback on most of these changes will be limited to those developers with the wherewithal to build Python from source. Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints). However, I would *like* to have months rather than weeks to act on any feedback we do receive. I'm not asking the release team to do any more work - I'm just asking for a chunk of it to be brought forward a few months. If I was asking for an *extra* release, I could understand resistance to the idea, but what's the concrete benefit of *delaying* the first alpha release by 4 months from when I'm hoping to see it happen? Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed schedule for Python 3.4
On 10/03/2012 04:55 PM, Nick Coghlan wrote: Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints). If you can show me people who use the alphas who want them earlier, I'll consider it. So far the only person who's said they want them is you, and IIUC you won't be a consumer of the alpha per se. Begging for feedback doesn't mean you'll get any, //arry/ ___ 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] Proposed schedule for Python 3.4
> If you can show me people who use the alphas who want them earlier, I'll > consider it. So far the only person who's said they want them is you, and > IIUC you won't be a consumer of the alpha per se. > > Begging for feedback doesn't mean you'll get any, I haven't done any Python core development work in quite awhile, but BITD, I always just used the current tip of whatever version control system we happened to be using. That would automatically get me all the pre-release versions. No need to beg. :-) 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] Proposed schedule for Python 3.4
On Wed, 03 Oct 2012 20:25:17 +0530, Nick Coghlan wrote: > On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote: > > I don't agree. It's my understanding that the alphas are largely ignored, > > and having them earlier would hardly make them more relevant. > > I would appreciate it you stopped promoting this myth. Each step in > the release process widens the pool of people providing feedback. Some > are providing feedback (and patches!) right the way through by > building their own copy of Python from source, a few start poking > around with the first alpha, more wait for feature freeze, we get a > whole slew of people that wait until the release candidates come out, > and then we get even more that don't check for backwards incompatible > changes until after the final release (so they have to wait until the > x.y.1 release before they can upgrade). > > Yes, the pool is substantially smaller in the early phases, but > phrases like "largely ignored" do a grave disservice to our alpha > testers that provide early feedback when we have plenty of time to fix > problems, rather than leaving their checks to the last minute and > forcing us to choose between delaying the release and shipping with > known defects. I don't have any data to back this up, but it is my impression that more distributions are providing access to alpha releases in their "testing" package trees. As Python continues to grow in importance[1], the number of people interacting with Python on the distribution development teams[2] increases, and therefor the number of people likely to run alphas for testing increases. So even if Larry were right *now*, he isn't right for the future, and we should do all we can to nurture an increasing culture of alpha-testing. --David [1] in case anyone hasn't noticed, we *are* a growing community, regardless of where various analytics put us relative to other languages :) [2] I include things like macports in this category, though I have no experience myself with their culture ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 8:43 PM, Larry Hastings wrote: > Begging for feedback doesn't mean you'll get any, I received a fair number of complaints from people that wanted to experiment with yield from, but couldn't, because the first alpha wasn't out yet and they weren't sufficiently interested to go to the effort of building their own copy of Python. *People like to try out the new versions*, so I have often received useful feedback during alpha periods - all it takes is one interested person from outside the core development team to get interested in a new feature and we can have a useful conversation. By *refusing* to release the alpha early you are *guaranteeing* I won't get the early feedback I want on the new features that are likely to come in 3.4. That's your prerogative as RM of course, but you haven't given any reason beyond the circular "I don't care about enabling feedback from people that can't or won't build from source, because people that can't or won't build from source don't provide useful feedback". I'm *not* happy about that attitude, because it's based on a blatantly false premise. If it was true, we wouldn't bother with alpha releases *at all*, and instead just skip straight to feature freeze and beta releases. Give me a reason like "I don't want to because I want to concentrate the release management work into a 6 month period", and I'll accept it, but don't try to rationalise it with statements about user feedback that I know from experience to be untrue. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 5:27 PM, Nick Coghlan wrote: > On Wed, Oct 3, 2012 at 8:43 PM, Larry Hastings wrote: >> Begging for feedback doesn't mean you'll get any, > > I received a fair number of complaints from people that wanted to > experiment with yield from, but couldn't, because the first alpha > wasn't out yet and they weren't sufficiently interested to go to the > effort of building their own copy of Python. > How about having nightly builds then? ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 10:13 AM, Larry Hastings wrote: > On 10/03/2012 04:55 PM, Nick Coghlan wrote: > > Regardless of when the first alpha happens, I'll be promoting the hell > out of it, begging for feedback on any of these changes that are > available by then (which should be quite a few, given the preceding > PyCon US sprints). > > > If you can show me people who use the alphas who want them earlier, I'll > consider it. So far the only person who's said they want them is you, and > IIUC you won't be a consumer of the alpha per se. > > Begging for feedback doesn't mean you'll get any, This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored... The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers. ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 8:58 PM, Brian Curtin wrote: > This doesn't answer the question of the users wanting the alphas > earlier, but they're certainly more than largely ignored... > > The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 > downloads of 3.3a2 Windows installers. So, there's 5000 people that could provide advance feedback that I would then have a few months to act on? Sounds useful to me. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 8:59 PM, Maciej Fijalkowski wrote: > On Wed, Oct 3, 2012 at 5:27 PM, Nick Coghlan wrote: >> On Wed, Oct 3, 2012 at 8:43 PM, Larry Hastings wrote: >>> Begging for feedback doesn't mean you'll get any, >> >> I received a fair number of complaints from people that wanted to >> experiment with yield from, but couldn't, because the first alpha >> wasn't out yet and they weren't sufficiently interested to go to the >> effort of building their own copy of Python. >> > > How about having nightly builds then? Nightly builds are a lot of work to setup and keep running smoothly, and the rate of change isn't high enough to justify them. I proposed to Larry originally that we start the alphas 6 months after 3.3.0, but he didn't like that idea, so I since reduced it to simply doing alpha 1 early so that it din't mean any more work for the release team. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 8:55 AM, Nick Coghlan wrote: > I *can't* effectively trial > those changes on PyPI (except perhaps some of the disassembly > changes), and I don't have the resources to create and distribute > Windows and Mac OS X installers on my own. That means, before the > release of 3.4a1, any feedback on most of these changes will be > limited to those developers with the wherewithal to build Python from > source. Would it help to have automated nightly builds that include those installers (if that's even feasible)? I'm not opposed to an earlier alpha as well, but some of the concern you have would be additionally addressed by such nightly builds. -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] Should vars() return modifiable dict?
On 03/10/12 18:54, Serhiy Storchaka wrote:
For locals vars() returns... hmm, partially modifiable dict:
>> def f():
... x = 42
... print(vars())
... vars()['x'] = 43
... vars()['y'] = 44
... print(x, vars())
...
>> f()
{'x': 42}
42 {'y': 44, 'x': 42}
Should behavior of vars() be corrected for locals?
I believe you are misinterpreting what you are seeing. In this case,
vars() simply returns locals(), which is an ordinary dict, but changes
to that dict are not guaranteed to propagate to the actual local
variables themselves. You make changes to that dict, then call vars()
again, which returns a fresh locals() dict. So what you are seeing is
simply a side-effect of the fact that changes to locals() may not
actually effect the local variables.
Note that in IronPython, the behaviour of your code is different:
steve@runes:~$ ipy
IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
def f():
... x = 42
... print(vars())
... vars()['x'] = 43
... vars()['y'] = 44
... print(x, vars())
...
f()
{'x': 42}
(43, {'y': 44, 'x': 43})
Should vars() for objects with __slots__ [1] returns modifiable or
non-modifiable dict?
[1] http://bugs.python.org/issue13290
You are assuming that the behaviour of vars(obj) should change. I don't think
that is necessarily the case.
vars(obj) is defined as returning the object __dict__ attribute. If an object
has no __dict__, vars() should (pick one):
1) Keep the current behaviour and raise an exception.
2) Return a regular dict containing {slot: value} for each of the slots.
Since the dict is a copy, changes to the dict will not effect the
original object.
3) Return a dictproxy containing {slot: value} for each of the slots.
Since the dictproxy does not support item assignment, you can't
modify it.
4) Return some other proxy object such that changes to the dict will
also change the object's slot attributes.
I find myself unable to choose between 2) and 4), which suggests that
the status quo wins and we keep the current behaviour.
--
Steven
___
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] Proposed schedule for Python 3.4
On 3 October 2012 16:13, Larry Hastings wrote: > On 10/03/2012 04:55 PM, Nick Coghlan wrote: > > Regardless of when the first alpha happens, I'll be promoting the hell > out of it, begging for feedback on any of these changes that are > available by then (which should be quite a few, given the preceding > PyCon US sprints). > > > If you can show me people who use the alphas who want them earlier, I'll > consider it. So far the only person who's said they want them is you, and > IIUC you won't be a consumer of the alpha per se. > > Begging for feedback doesn't mean you'll get any, FWIW, I *will* be downloading and installing the 3.4 alphas as soon as they come out. How much I'll *use* them depends on what issues I find with them - but that's the whole point, I'll feed back my experiences. I will not build from source, or download nightly builds routinely. Doing so implies a commitment to track the latest build that I can't offer. Paul. ___ 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] Proposed schedule for Python 3.4
On Oct 03, 2012, at 11:22 AM, R. David Murray wrote: >I don't have any data to back this up, but it is my impression that more >distributions are providing access to alpha releases in their "testing" >package trees. Ubuntu and Debian generally does, thanks to Matthias's great work. Python 3.3's been available (though obviously not the default) in Ubuntu 12.10 for a while now, and in Debian experimental, and we have started to get package build failure reports related to it: http://bugs.debian.org/cgi-bin/[email protected];tag=python3.3 It's not that much yet though, and I'm not sure if having the alphas available really helps with that, but it *is* nice to be able to make alphas available to our users via experimental, PPAs, etc. so that folks can play with it much more easily. >As Python continues to grow in importance[1], the number of people >interacting with Python on the distribution development teams[2] increases, >and therefor the number of people likely to run alphas for testing increases. >So even if Larry were right *now*, he isn't right for the future, and we >should do all we can to nurture an increasing culture of alpha-testing. Definitely. >[1] in case anyone hasn't noticed, we *are* a growing community, regardless >of where various analytics put us relative to other languages :) Which is *fantastic*! Cheers, -Barry ___ 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] Proposed schedule for Python 3.4
On 10/03/2012 05:27 PM, Nick Coghlan wrote: That's your prerogative as RM of course, but you haven't given any reason beyond the circular "I don't care about enabling feedback from people that can't or won't build from source, because people that can't or won't build from source don't provide useful feedback". That's not quite what I said. I simply said that the alphas are largely ignored. My perspective is that most people ignore the alphas and only get interested when the software "solidifies". Having more alphas, or having earlier alphas, doesn't mean we'll have more people interested in the alphas. Adding more alphas (as you have previously suggested) adds additional workload on myself and the rest of the release team--I don't know what the Mac build is like, but I know Martin has to intercede manually to coax a Windows installer out of the build. I'm loathe to burn their time for what I perceive as little return. Changing an existing alpha to be earlier doesn't alter the workload, but I fear it makes the alpha less relevant. Evaluating alphas / betas takes an investment of time, and whether or not a potential alpha user makes that investment depends on what they expect to get out of testing the alpha. If they're doing it out of the goodness of their hearts, just to help Python--well, that's fabulous, and more / earlier alphas might actually interest them. But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha. In short, I see the scheduling of alphas as a tradeoff between "early enough that we'll have time to fix things" and "late enough that the software is reasonably complete". What it really comes down to: I'm a first-time RM, and I lack the courage/wisdom to overrule what appears to be a reasonable status quo. I feel I don't have to defend the decision to maintain the status quo; I feel instead you have to make a case for changing it. So far all I recall seeing from you are assertions. I'd like to see some harder data. On 10/03/2012 05:28 PM, Brian Curtin wrote: The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers. I'd love to know how much feedback we got as a result of these downloads. Do we have any way of telling? And out of curiosity, how many 3.3.0 final Windows installers have been downloaded so far? On 10/03/2012 05:29 PM, Maciej Fijalkowski wrote: How about having nightly builds then? We simply don't have a fully-automated process to produce installers for all platforms. In fact, I fear we don't have a fully-automated process to produce installers for /any/ platforms. On 10/03/2012 05:40 PM, Paul Moore wrote: FWIW, I *will* be downloading and installing the 3.4 alphas as soon as they come out. How much I'll *use* them depends on what issues I find with them - but that's the whole point, I'll feed back my experiences. Excellent, thanks for the data! As long as you're volunteering interesting data ;-), what platform will you be testing on? And what is your purpose in downloading the alphas--just Good Samaritan-ism, or integration testing with software you care about, or what? //arry/ ___ 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] Proposed schedule for Python 3.4
On Wed, Oct 3, 2012 at 11:02 AM, Larry Hastings wrote: > > On 10/03/2012 05:28 PM, Brian Curtin wrote: > > The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 > downloads of 3.3a2 Windows installers. > > > I'd love to know how much feedback we got as a result of these downloads. > Do we have any way of telling? Not really, but I guess we could query the tracker for the time frame the alphas were fresh and poke around. > And out of curiosity, how many 3.3.0 final Windows installers have been > downloaded so far? 27,947 32-bit and 15,816 64-bit installers downloaded in September...which is fun considering that was across the last two days of the month, on a weekend. So far in October we're at 32,449 32-bit and 22,221 64-bit downloads. ___ 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] Proposed schedule for Python 3.4
Nick Coghlan writes: > I proposed to Larry originally that we start the alphas 6 months > after 3.3.0, I like this idea better, even though to keep the total workload constant you'd need to more than double the interval between alphas. Still, a 10- or 12-month release schedule feels like a much bigger commitment to me (and I have managed a release that took 6 months, so I do know what that feels like for real). > but he didn't like that idea, so I since reduced it to simply doing > alpha 1 early so that it din't mean any more work for the release > team. Heck, if you're only going to have *one* early alpha, you could do it yourself, and see if you can persuade the installer builders to volunteer one extra build. ___ 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] Proposed schedule for Python 3.4
On Wed, 03 Oct 2012 18:02:03 +0200, Larry Hastings wrote: > Changing an existing alpha to be earlier doesn't alter the workload, but > I fear it makes the alpha less relevant. Evaluating alphas / betas > takes an investment of time, and whether or not a potential alpha user > makes that investment depends on what they expect to get out of testing > the alpha. If they're doing it out of the goodness of their hearts, > just to help Python--well, that's fabulous, and more / earlier alphas > might actually interest them. But my suspicion is that most people who > try the alphas are doing early integration testing with their own > stuff. For those people, the earlier the alpha, the less interesting it > probably is to them. Earlier means that the software will be less > finished. It will be buggier, it won't have as many features as the > beta will. As a result it won't be as revealing--or as relevant--as a > later alpha or even a beta. If that's their perspective, I suspect > they'll be less likely to try an earlier alpha. In my perception (again, I can't point to any raw data) there is an opposite dynamic that happens in stable projects that produce alphas throughout the release cycle. In those projects, people will often run the alphas, even in production[1], in order to get the new features sooner. Python is a stable project. Even our alphas do not as a rule brown bag, though their suitability for specific projects depends on the bugs found. I think Python *could* be in this camp, if we wanted to be. (I'm not addressing release-team load here, I'm just making an observation.) --David [1] I am *not* advocating running an alpha in production, but for some projects "production" is a small enough audience that they can get away with it.) ___ 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] Proposed schedule for Python 3.4
On Wed, 03 Oct 2012 11:19:57 -0500, Brian Curtin wrote: > On Wed, Oct 3, 2012 at 11:02 AM, Larry Hastings wrote: > > > > On 10/03/2012 05:28 PM, Brian Curtin wrote: > > > > The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 > > downloads of 3.3a2 Windows installers. > > > > > > I'd love to know how much feedback we got as a result of these downloads. > > Do we have any way of telling? > > Not really, but I guess we could query the tracker for the time frame > the alphas were fresh and poke around. There *were* bug reports during the alpha phase. A number of regressions were caught. Also, there were more alpha-phase bug reports than I remember getting for 3.2. I remember thinking, "wow, cool, we're actually getting regression bug reports during the alpha phase, people must actually be testing this time". --David ___ 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] Proposed schedule for Python 3.4
Nick Coghlan wrote: On Wed, Oct 3, 2012 at 8:58 PM, Brian Curtin wrote: This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored... The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers. So, there's 5000 people that could provide advance feedback that I would then have a few months to act on? Sounds useful to me. I have to agree. +1 for an early alpha. Call it alpha 0 if you like. ;) ~Ethan~ ___ 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] Proposed schedule for Python 3.4
On 3 October 2012 17:34, R. David Murray wrote: > There *were* bug reports during the alpha phase. A number of regressions > were caught. Also, there were more alpha-phase bug reports than > I remember getting for 3.2. I remember thinking, "wow, cool, we're > actually getting regression bug reports during the alpha phase, people > must actually be testing this time". One possibly-relevant point is that I caught some bugs in packaging that could only be properly investigated from an installer-based build. The source build layout on Windows is different, and it mattered to packaging. (Arguably, that itself was a bug in packaging, and it shouldn't have mattered, but nevertheless). As far as I can tell, it is *not* possible (in any practical sense) to create a production-layout install on Windows without building the MSIs (which definitely takes installing extra tools and things to complete - more than I ever managed to do successfully). Paul. ___ 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] Proposed schedule for Python 3.4
On 03.10.12 19:02, Larry Hastings wrote: But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha. I wholeheartedly agree with Larry. Personally I looked for the first time near Python 3.3 after release of the first alpha (before a lot of years followed the development from a distance), but if alpha came out much earlier and would be less mature, I would have probably ignored it. Of course, this is only my personal case, I can't speak for other people. ___ 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] Proposed schedule for Python 3.4
On 10/03/2012 06:26 PM, R. David Murray wrote: On Wed, 03 Oct 2012 18:02:03 +0200, Larry Hastings wrote: Changing an existing alpha to be earlier doesn't alter the workload, but I fear it makes the alpha less relevant. Evaluating alphas / betas takes an investment of time, and whether or not a potential alpha user makes that investment depends on what they expect to get out of testing the alpha. If they're doing it out of the goodness of their hearts, just to help Python--well, that's fabulous, and more / earlier alphas might actually interest them. But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha. In my perception (again, I can't point to any raw data) there is an opposite dynamic that happens in stable projects that produce alphas throughout the release cycle. In those projects, people will often run the alphas, even in production[1], in order to get the new features sooner. Python is a stable project. Even our alphas do not as a rule brown bag, though their suitability for specific projects depends on the bugs found. I think Python *could* be in this camp, if we wanted to be. I agree. (I'm not addressing release-team load here, I'm just making an observation.) As for release-team load: after the first alpha is done the subsequent ones are quite lightweight from the main RM perspective. Regarding the Mac/Windows builds, there's no law saying that only one person is allowed to make binaries for a given version. We should by now have at least two for each platform; Ned and Ronald for Mac, and AFAIK Brian Curtin has volunteered to fill in for Martin in emergencies anyway. As soon as betas arrive, of course it makes sense for the release team to stay the same to ensure a smooth road to final. Georg ___ 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] Proposed schedule for Python 3.4
On 2012-10-03 16:28, Brian Curtin wrote: On Wed, Oct 3, 2012 at 10:13 AM, Larry Hastings wrote: On 10/03/2012 04:55 PM, Nick Coghlan wrote: Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints). If you can show me people who use the alphas who want them earlier, I'll consider it. So far the only person who's said they want them is you, and IIUC you won't be a consumer of the alpha per se. Begging for feedback doesn't mean you'll get any, This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored... The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers. I downloaded the alphas to test the support for PEP 393 I'd added to the regex module. Not having to build Python 3.3 from source certainly helped _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] Proposed schedule for Python 3.4
On Wed, 3 Oct 2012 20:25:17 +0530 Nick Coghlan wrote: > On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote: > > I don't agree. It's my understanding that the alphas are largely ignored, > > and having them earlier would hardly make them more relevant. > > I would appreciate it you stopped promoting this myth. Each step in > the release process widens the pool of people providing feedback. Well, if you look at the download statistics at http://www.python.org/webstats/ or even at the bug influx when publishing an alpha, it seems clear to me that alphas have almost no impact. Only rcs seem to gather significant interest from the broader community. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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] Proposed schedule for Python 3.4
On Wed, 3 Oct 2012 20:05:24 +0200 Antoine Pitrou wrote: > On Wed, 3 Oct 2012 20:25:17 +0530 > Nick Coghlan wrote: > > On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote: > > > I don't agree. It's my understanding that the alphas are largely ignored, > > > and having them earlier would hardly make them more relevant. > > > > I would appreciate it you stopped promoting this myth. Each step in > > the release process widens the pool of people providing feedback. > > Well, if you look at the download statistics at > http://www.python.org/webstats/ or even at the bug influx when > publishing an alpha, it seems clear to me that alphas have almost no > impact. Erm, I hadn't seen Brian's reply before sending this. Apparently there *are* people who download the alphas, which for some reason I had overlooked in the stats pages. My mistake, sorry. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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] Proposed schedule for Python 3.4
Zitat von Larry Hastings : I welcome your feedback--without any further input I'll go ahead and post this as a PEP in a week or so. I personally feel that the release period is too long. Is it really necessary to start with the release more than 6 month before the scheduled release date? Starting with alpha 3 (i.e. September 2013) seems sufficient to me. 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] Proposed schedule for Python 3.4
Zitat von Skip Montanaro : I've roughed out a release schedule Is there a rough list of changes for 3.4 written down somewhere, or is that only to be inferred based on PEPs whose Python-Version header reads "3.4"? How confident are you that the schedule you've proposed gives enough time for proposed changes to be implemented and to stablize? I think it's really vice-versa. We traditionally follow a timed process: we release when enough time has passed, and include features which are ready by the time we release. 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] Proposed schedule for Python 3.4
Zitat von Eric Snow : On Wed, Oct 3, 2012 at 8:55 AM, Nick Coghlan wrote: I *can't* effectively trial those changes on PyPI (except perhaps some of the disassembly changes), and I don't have the resources to create and distribute Windows and Mac OS X installers on my own. That means, before the release of 3.4a1, any feedback on most of these changes will be limited to those developers with the wherewithal to build Python from source. Would it help to have automated nightly builds that include those installers (if that's even feasible)? We once had nightly builds of the Windows installers. It required a dedicated buildbot operator, since the process tended to break. We still do have OSX nightly installers: http://buildbot.python.org/daily-dmg/ 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] Proposed schedule for Python 3.4
Zitat von Maciej Fijalkowski : On Wed, Oct 3, 2012 at 5:27 PM, Nick Coghlan wrote: On Wed, Oct 3, 2012 at 8:43 PM, Larry Hastings wrote: Begging for feedback doesn't mean you'll get any, I received a fair number of complaints from people that wanted to experiment with yield from, but couldn't, because the first alpha wasn't out yet and they weren't sufficiently interested to go to the effort of building their own copy of Python. How about having nightly builds then? We actually do have nightly builds. 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] Proposed schedule for Python 3.4
Zitat von Nick Coghlan : Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints). However, I would *like* to have months rather than weeks to act on any feedback we do receive. I'm not asking the release team to do any more work - I'm just asking for a chunk of it to be brought forward a few months. If I was asking for an *extra* release, I could understand resistance to the idea, but what's the concrete benefit of *delaying* the first alpha release by 4 months from when I'm hoping to see it happen? I wouldn't mind having alpha 1 in April 2013, and alpha 2 in October 2013. I share Larry's skepticism, and actually fear that it may confuse users (which find that they test something completely different from what gets released). However, I don't mind supporting this strategy anyway as an experiment. 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] Proposed schedule for Python 3.4
2012/10/3 Larry Hastings : > Other proposed large-scale changes: > [...] > * A standard event-loop interface (PEP by Jim Fulton pending) Really? Was this discussed somewhere? I'd like to know more about it. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/ ___ 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] Proposed schedule for Python 3.4
On Thu, 04 Oct 2012 03:14:11 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= wrote: > 2012/10/3 Larry Hastings : > > > Other proposed large-scale changes: > > [...] > > * A standard event-loop interface (PEP by Jim Fulton pending) > > Really? Was this discussed somewhere? I'd like to know more about it. I believe it was discussed at the Language Summit at the last Pycon. As I recall there was at least one other person interested in helping with it, but I don't remember who. --David ___ 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] Proposed schedule for Python 3.4
[email protected] writes: > I wouldn't mind having alpha 1 in April 2013, and alpha 2 in October 2013. > I share Larry's skepticism, and actually fear that it may confuse users > (which find that they test something completely different from what gets > released). I don't really think you need to worry. The Mallory-style testers[1] who download early alphas generally don't have specific expectations that it will correspond to the eventual release in my experience. I have little experience with testers who download alphas to get a head start on integration work, but I suppose Larry is right, you'll lose a few of those if an alpha is "too early". I suspect that those folks mostly listen to an internal clock, not so much to release announcements, and download the freshest release when they are ready to start that kind of work. Those who decide *not* to download alpha 1 because "it's too old/incomplete, I'll wait for alpha 2" will be a subset, I suspect a minority, of those ready to get an alpha for integration testing at any given time. OTOH, is it really that big a loss? If I'm right, they *will* get alpha 2. In fact, you might find a larger than usual response from those folks for alpha 1 because Nick will be out advertising "these changes are big, guys, both you and we want testing early!" Except that unlike most advertising, Nick's pretty plausible. At least, that's Nick's main point for doing this experiment *now* as I understand it. (I gather he agrees with David about a trend to "continuous alpha", but that's a separate though related issue.) Footnotes: [1] "Why did you download the alpha?" "Because it's there." ___ 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] Using environment variables problematic for embedded python.
Hi,
We've run into an issue recently with blender3d on ms-windows where we
want to enforce the encoding is UTF-8 with the embedded python
interpreter.
(the encoding defaults to cp437).
I naively thought setting the environment variable before calling
Py_Initialize() would work, but the way python DLL loads, it gets its
own environment variables that cant be modified directly [1].
eg, _putenv("PYTHONIOENCODING=utf-8:surrogateescape");
We had bug reports by windows users not able to export files because
the stdout errors on printing paths with unsupported encoding. [2],[3]
---
Of course we could distribute blender with a bat file launcher that
sets env variables, or ask the user to set their env variable - but I
dont think this is really a good option.
I tried overriding the stderr & stdout, but this caused another bug in
a part of out code that catches exception messages from the stderr.
[4]
import sys, io
sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8',
errors='surrogateescape', line_buffering=True)
sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8',
errors='surrogateescape', line_buffering=True)
IMHO either of these solutions would be fine.
* have a PyOS_PutEnv() function, gettext has gettext_putenv() to
workaround this problem.
* manage this the same as Py_GetPythonHome(), which can be defined by
the embedding application to override the default.
Id like to know if there is some known solution to workaround this
issue, if not - would either of these would be acceptable in python
(can write up a patch if it helps)
Regards,
Campbell
---
[1]
http://stackoverflow.com/questions/5153547/environment-variables-are-different-for-dll-than-exe
[2] http://projects.blender.org/tracker/index.php?func=detail&aid=32750
[3] http://projects.blender.org/tracker/index.php?func=detail&aid=31555
[4] http://projects.blender.org/tracker/?func=detail&aid=32720
___
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] Using environment variables problematic for embedded python.
On Thu, Oct 4, 2012 at 1:35 PM, Campbell Barton wrote:
> Hi,
>
> We've run into an issue recently with blender3d on ms-windows where we
> want to enforce the encoding is UTF-8 with the embedded python
> interpreter.
> (the encoding defaults to cp437).
>
> I naively thought setting the environment variable before calling
> Py_Initialize() would work, but the way python DLL loads, it gets its
> own environment variables that cant be modified directly [1].
> eg, _putenv("PYTHONIOENCODING=utf-8:surrogateescape");
>
> We had bug reports by windows users not able to export files because
> the stdout errors on printing paths with unsupported encoding. [2],[3]
>
> ---
>
> Of course we could distribute blender with a bat file launcher that
> sets env variables, or ask the user to set their env variable - but I
> dont think this is really a good option.
>
> I tried overriding the stderr & stdout, but this caused another bug in
> a part of out code that catches exception messages from the stderr.
> [4]
> import sys, io
> sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8',
> errors='surrogateescape', line_buffering=True)
> sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8',
> errors='surrogateescape', line_buffering=True)
>
>
>
> IMHO either of these solutions would be fine.
>
> * have a PyOS_PutEnv() function, gettext has gettext_putenv() to
> workaround this problem.
>
> * manage this the same as Py_GetPythonHome(), which can be defined by
> the embedding application to override the default.
>
>
> Id like to know if there is some known solution to workaround this
> issue, if not - would either of these would be acceptable in python
> (can write up a patch if it helps)
>
> Regards,
> Campbell
>
> ---
>
> [1]
> http://stackoverflow.com/questions/5153547/environment-variables-are-different-for-dll-than-exe
> [2] http://projects.blender.org/tracker/index.php?func=detail&aid=32750
> [3] http://projects.blender.org/tracker/index.php?func=detail&aid=31555
> [4] http://projects.blender.org/tracker/?func=detail&aid=32720
To follow up and give a correction to overwriting sys.stdout/stderr,
The issue seemed to be that __stderr__/__stdout__ was later
overwritten, loosing the original reference to the buffer (maybe
refcount issue here?), either way it would silence the output.
import sys, io
sys.__stdout__ = sys.stdout =
io.TextIOWrapper(io.open(sys.stdout.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)
sys.__stderr__ = sys.stderr =
io.TextIOWrapper(io.open(sys.stderr.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)
This all works as expected without bug [4] (above), however on exit I
get an assert in MSVCR90.DLL's write.c (called from python32_d.dll):
_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);
I'd rather not loose more time debugging why this assert happens,
IMHO this is too low-level a way to change the encoing of stdio/stderr
and error-prone too, so some way to reliably set PYTHONIOENCODING from
a program embedding python is still needed.
--
- Campbell
___
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] Using environment variables problematic for embedded python.
This seems more fit for the tracker; can you file there? (Then post the
issue link here.) I do think you have a legitimate use case to set the
default encoding to utf-8. (Though there may be a way already.) Does Python
3.3 have te same bug?
On Wednesday, October 3, 2012, Campbell Barton wrote:
> On Thu, Oct 4, 2012 at 1:35 PM, Campbell Barton
> >
> wrote:
> > Hi,
> >
> > We've run into an issue recently with blender3d on ms-windows where we
> > want to enforce the encoding is UTF-8 with the embedded python
> > interpreter.
> > (the encoding defaults to cp437).
> >
> > I naively thought setting the environment variable before calling
> > Py_Initialize() would work, but the way python DLL loads, it gets its
> > own environment variables that cant be modified directly [1].
> > eg, _putenv("PYTHONIOENCODING=utf-8:surrogateescape");
> >
> > We had bug reports by windows users not able to export files because
> > the stdout errors on printing paths with unsupported encoding. [2],[3]
> >
> > ---
> >
> > Of course we could distribute blender with a bat file launcher that
> > sets env variables, or ask the user to set their env variable - but I
> > dont think this is really a good option.
> >
> > I tried overriding the stderr & stdout, but this caused another bug in
> > a part of out code that catches exception messages from the stderr.
> > [4]
> > import sys, io
> > sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8',
> > errors='surrogateescape', line_buffering=True)
> > sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8',
> > errors='surrogateescape', line_buffering=True)
> >
> >
> >
> > IMHO either of these solutions would be fine.
> >
> > * have a PyOS_PutEnv() function, gettext has gettext_putenv() to
> > workaround this problem.
> >
> > * manage this the same as Py_GetPythonHome(), which can be defined by
> > the embedding application to override the default.
> >
> >
> > Id like to know if there is some known solution to workaround this
> > issue, if not - would either of these would be acceptable in python
> > (can write up a patch if it helps)
> >
> > Regards,
> > Campbell
> >
> > ---
> >
> > [1]
> http://stackoverflow.com/questions/5153547/environment-variables-are-different-for-dll-than-exe
> > [2] http://projects.blender.org/tracker/index.php?func=detail&aid=32750
> > [3] http://projects.blender.org/tracker/index.php?func=detail&aid=31555
> > [4] http://projects.blender.org/tracker/?func=detail&aid=32720
>
> To follow up and give a correction to overwriting sys.stdout/stderr,
> The issue seemed to be that __stderr__/__stdout__ was later
> overwritten, loosing the original reference to the buffer (maybe
> refcount issue here?), either way it would silence the output.
>
>
> import sys, io
> sys.__stdout__ = sys.stdout =
> io.TextIOWrapper(io.open(sys.stdout.fileno(), "wb", -1),
> encoding='utf-8', errors='surrogateescape', newline="\n",
> line_buffering=True)
> sys.__stderr__ = sys.stderr =
> io.TextIOWrapper(io.open(sys.stderr.fileno(), "wb", -1),
> encoding='utf-8', errors='surrogateescape', newline="\n",
> line_buffering=True)
>
> This all works as expected without bug [4] (above), however on exit I
> get an assert in MSVCR90.DLL's write.c (called from python32_d.dll):
> _VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);
>
> I'd rather not loose more time debugging why this assert happens,
> IMHO this is too low-level a way to change the encoing of stdio/stderr
> and error-prone too, so some way to reliably set PYTHONIOENCODING from
> a program embedding python is still needed.
>
> --
> - Campbell
> ___
> 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 (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] Proposed schedule for Python 3.4
Am 04.10.2012 um 03:38 schrieb R. David Murray : >>> Other proposed large-scale changes: >>> [...] >>> * A standard event-loop interface (PEP by Jim Fulton pending) >> >> Really? Was this discussed somewhere? I'd like to know more about it. > > I believe it was discussed at the Language Summit at the last Pycon. > As I recall there was at least one other person interested in helping > with it, but I don't remember who. T’was lvh and I remember doing some cheap spelling checking on it back at EuroPython 20_11_ but the work seems to has stalled 9 months ago. Adding him to the loop. ___ 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
