Re: [Python-Dev] Data descriptor doc/implementation inconsistency
Michael Foord wrote: >> Note that the behaviour here is still different from that of a data >> descriptor: with a data descriptor, once it gets shadowed in the >> instance dictionary, the descriptor is ignored *completely*. The only >> way to get the descriptor involved again is to eliminate the shadowing. >> The non-data descriptor with only __set__ is just choosing not to >> override the attribute lookup process. >> >> > > Does that mean we need a third class of descriptors that are neither > data descriptors nor non-data descriptors? Not really - leaving out __get__ when defining __set__ just creates a data descriptor that happens to use the default attribute look-up process rather than defining a different one. (Note that I had the data/non-data terminology backwards in my previous message - I tend to think of the two kinds of descriptor as enforced and non-enforced respectively precisely because I have to think about it to remember that "functions are non-data descriptors and properties are data descriptors, hence non-data descriptors only define __get__ while data descriptors define __set__". I don't find the data/non-data terminology intuitive at all) 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] [RELEASED] Python 2.7 alpha 2
Lennart Regebro wrote: > And, I just realized, it doesn't warn for you using cmp or __cmp__ > either, and 2to3 won't fix that, so it should actually warn for it. I have a vague recollection that we tried to warn for that and ended up nixing the warning due to vast swarms of false alarms (or because you couldn't write correct 2.x code without triggering it). I'd be happy for someone to prove my recollection wrong though (i.e. by writing a patch that implements such warnings). 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] [RELEASED] Python 2.7 alpha 2
David Lyon wrote: >> This has nothing to do with pushing 3.x, but all with managing >> available manpower and still providing quality software. > > Python 3.x needs more carrots. As Guido has said a few times, the gains are far greater for *new* Python developers than they are for existing ones. Existing developers have to unlearn old habits and wait for libraries they already use to get ported. New developers can just get started with a much cleaner language. They don't have as rich a 3rd party ecosystem on Python 3 as they would on Python 2.x at this point in time, but unlike existing developers they also have the luxury of cherry-picking just those packages that already have Python 3 support. 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] topics I plan to discuss at the language summit
Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit : > > For example, there are currently over > 1500 open issues with no stage set, some of which seemingly haven't been > read by anyone at all. I think most issues /have/ been read. It's just that for many of them, nobody is interested enough in or feels competent enough for fixing them. > Would a properly set stage field save issues from > falling into a black hole? I don't think this has anything to do with properly setting the stage field. We just have limited time and manpower. Perhaps one of our goals should be to reach out more to potential contributors. > Food for thought: according to the last tracker summary, there are over > 1000 open issues with a patch, and issues stay open an average of 700 > days (median 450). As for open issues with a patch, a "code review" button sending this patch to Rietveld (or any other similar tool) is something many of us have been hoping for :-) It would make reviewing easier, faster and more thorough (because you visualize things better than by looking at a diff). 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] topics I plan to discuss at the language summit
Le Tue, 12 Jan 2010 10:20:27 +, Antoine Pitrou a écrit : > > I don't think this has anything to do with properly setting the stage > field. We just have limited time and manpower. Perhaps one of our goals > should be to reach out more to potential contributors. Speaking of which, Steve had something to say about it: http://holdenweb.blogspot.com/2009/11/comments-or-not-public-or- private.html cheers 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] topics I plan to discuss at the language summit
Antoine Pitrou wrote: > Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit : >> For example, there are currently over >> 1500 open issues with no stage set, some of which seemingly haven't been >> read by anyone at all. > > I think most issues /have/ been read. It's just that for many of them, > nobody is interested enough in or feels competent enough for fixing them. There are actually a whole host of reasons issues can stagnate: - a feature request may seem reasonable (hence it doesn't get rejected outright), but the right API may not be clear (hence it doesn't get implemented in the near term) - a patch may be reviewed and found to have significant defects (or simply be overreaching the stated goal) but the original patch poster loses interest after meeting resistance in their ambition to fix something that is "obviously" broken - a problem may simply be hard to fix in a backwards compatible way (or even at all!) Ultimately it boils down to Antoine's two categories (lack of interest and lack of relevant expertise to make a final decision) but there are a lot of different ways to get into those two buckets. Because we aren't ruthless about pruning those kinds of issues out of the tracker they're the ones that are going to accumulate over time. I'd actually be interested to know what the issue stats are like when RFEs are excluded and when the search is limited to the items flagged as 'easy'. If easy bug fix issues are taking a long time to get closed than that would bother me a lot more than RFEs that sit on the tracker for years. 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] [RELEASED] Python 2.7 alpha 2
On Jan 11, 2010, at 10:53 PM, Jack Diederich wrote: >3) 100% of the module level assignments in public projects were the >"__metaclass__ = type" variety which is why there isn't a fixer for >that. Also, a fixer would have been really, really ugly (munge every >class definition in this module because there is a top level >assignment). And almost certainly unnecessary. IME, those are all to easily make bare class definitions new style in Python 2. -Barry signature.asc Description: PGP signature ___ 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] [RELEASED] Python 2.7 alpha 2
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
>Actually there's a solution to this one too:
>
>FooBase = Meta('FooBase', (), {})
>class Foo(FooBase):
>...
>
>That should work in Python 2.X and 3.X.
Ugly, but good call! :)
>I've got argparse running on Python 2.3-3.1, and the changes were
>pretty easy. You can see them all in the revision here:
>
>http://code.google.com/p/argparse/source/detail?r=12
>
>I have aspirations of putting all of the tricks I learned up up on the
>Wiki somewhere, but I just haven't had the time.
The more resources we can provide people, both in code and in documentation,
the better.
Thanks!
-Barry
signature.asc
Description: PGP signature
___
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] [RELEASED] Python 2.7 alpha 2
On 12/01/2010 12:16, Barry Warsaw wrote:
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {})
class Foo(FooBase):
...
That should work in Python 2.X and 3.X.
Ugly, but good call! :)
There are all sorts of tricks. For example you can do exception handling
that works with pre-2.6 syntax and 3.0 with a bare except and using
sys.exc_info. It is horrible, but acceptable for short pieces of code (I
have a couple of small modules that do this).
I haven't yet tried converting larger code-bases to Python 3, but I
think the workflow advocated by Martin is greatly preferable to the
hacks and tricks needed to make the same codebase run under 2 & 3.
Michael
I've got argparse running on Python 2.3-3.1, and the changes were
pretty easy. You can see them all in the revision here:
http://code.google.com/p/argparse/source/detail?r=12
I have aspirations of putting all of the tricks I learned up up on the
Wiki somewhere, but I just haven't had the time.
The more resources we can provide people, both in code and in documentation,
the better.
Thanks!
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your
employer, to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS
AGREEMENTS") that I have entered into with your employer, its partners, licensors,
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me from any BOGUS AGREEMENTS
on behalf of your employer.
___
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] topics I plan to discuss at the language summit
Brett Cannon wrote: > Michael has given me the hg transition/stdlib time slot at the language > summit this year. In regards to that I plan to lead a discussion on: > > * where we are at w/ the Hg transition (Dirkjan should be there and I did a > blog post on this topic recently: > http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html) > * argparse (PEP 389) > * brief mention on still wanting to break out the stdlib from CPython > * an official policy on extension modules? (i.e. must have a pure Python > implementation which can mean a ctypes implementation unless given an > explicit waiver) > > That's everything from a stdlib perspective. I have half-baked ideas, but > nothing concrete enough to bring up unless people really want to discuss > stuff like how to potentially standardize module deprecation warnings, etc. > > In terms of me personally, I do plan to bring up at some point during the > summit these points which don't squarely fit during my time slot: > > * an official unofficial policy on how new proposed features should come to > us (i.e. working code to python-ideas with a shell of a PEP that includes > abstract and motivation -> hashed out PEP to python-dev -> pronouncement) > * any changes needed to the issue tracker to help with the workflow? (stage > field seems like a failed experiment and we now have several effective > triage people who can help w/ guiding changes) > > If there is something missing from the stdlib discussion that you think > should be brought up at the summit let me know. And if there is something > here you want to discuss before the summit let me know and I can start a > separate thread on it. Could you please put these things and the results up on the Python wiki ?! We're going to have a language summit at EuroPython this year as well and may want to continue/extend the discussion based on what you're doing at PyCon. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 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/ ::: 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] topics I plan to discuss at the language summit
On Tue, Jan 12, 2010 at 04:20, Antoine Pitrou wrote: > Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit : > > > > For example, there are currently over > > 1500 open issues with no stage set, some of which seemingly haven't been > > read by anyone at all. > > I think most issues /have/ been read. It's just that for many of them, > nobody is interested enough in or feels competent enough for fixing them. > > > Would a properly set stage field save issues from > > falling into a black hole? > > I don't think this has anything to do with properly setting the stage > field. We just have limited time and manpower. Perhaps one of our goals > should be to reach out more to potential contributors. Agreed, I didn't mean to place blame on the stage field, I just ran with how I view that field since it was mentioned. When I'm thinking in "code-writing developer mode" (tm), I'm more likely to go to issues which have a stage so I know what I'm going into -- what needs to be worked on. When I'm in project cleanup mode, I go by stageless issues -- what is necessary for this to begin or end work. Maybe others work differently...software projects take all kinds :-) Anyways, sorry for the off-topic. If this is a summit worthy discussion, cool. ___ 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] topics I plan to discuss at the language summit
On Tue, 12 Jan 2010 22:10:14 +1000, Nick Coghlan wrote: > There are actually a whole host of reasons issues can stagnate: > - a feature request may seem reasonable (hence it doesn't get rejected > outright), but the right API may not be clear (hence it doesn't get > implemented in the near term) > - a patch may be reviewed and found to have significant defects (or > simply be overreaching the stated goal) but the original patch poster > loses interest after meeting resistance in their ambition to fix > something that is "obviously" broken > - a problem may simply be hard to fix in a backwards compatible way (or > even at all!) I would add: - a patch is reviewed but the reviewer requests a second opinion before committing, which never arrives, and the original reviewer forgets about the issue. I have occasionally observed apparently moribund issues spring to life and get resolved when a triage person does something as simple as updating the releases to which an issue applies. > Ultimately it boils down to Antoine's two categories (lack of interest > and lack of relevant expertise to make a final decision) but there are a > lot of different ways to get into those two buckets. There's a third bucket here: lack of time. Sometimes there is interest and expertise, but no time. Worse, sometimes we end up waiting on the person with the expertise and interest but no time, when someone else with somewhat less expertise but more time should just go ahead and do the commit. (*That* one should be fixable.) > Because we aren't ruthless about pruning those kinds of issues out of > the tracker they're the ones that are going to accumulate over time. Another other category that hangs around in the tracker is items for which there simply isn't a consensus. I suppose those could be brought to python-dev for a final decision if someone wanted to tackle that task. And I don't think it is a lack of ruthlessness. I think it is the current community consensus that we leave these issues open in the tracker in case someone does come along and want to deal with them. (*) > I'd actually be interested to know what the issue stats are like when > RFEs are excluded and when the search is limited to the items flagged as > 'easy'. If easy bug fix issues are taking a long time to get closed than > that would bother me a lot more than RFEs that sit on the tracker for > years. I'd also be interested to know what the average and median lifetime of closed bug reports is. Not the metrics for open issues, but the metrics for closed ones. My theory is that we close a lot of bugs fairly promptly, but the ones in the above categories make the average age of *open* issues high. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls (*) For example, I'm currently going through all the open issues relating to the email package, and some of them are pretty darn old, yet still have useful content. ___ 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] topics I plan to discuss at the language summit
On Tue, Jan 12, 2010 at 05:09, M.-A. Lemburg wrote: > Brett Cannon wrote: > > Michael has given me the hg transition/stdlib time slot at the language > > summit this year. In regards to that I plan to lead a discussion on: > > > > * where we are at w/ the Hg transition (Dirkjan should be there and I did > a > > blog post on this topic recently: > > http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html) > > * argparse (PEP 389) > > * brief mention on still wanting to break out the stdlib from CPython > > * an official policy on extension modules? (i.e. must have a pure Python > > implementation which can mean a ctypes implementation unless given an > > explicit waiver) > > > > That's everything from a stdlib perspective. I have half-baked ideas, but > > nothing concrete enough to bring up unless people really want to discuss > > stuff like how to potentially standardize module deprecation warnings, > etc. > > > > In terms of me personally, I do plan to bring up at some point during the > > summit these points which don't squarely fit during my time slot: > > > > * an official unofficial policy on how new proposed features should come > to > > us (i.e. working code to python-ideas with a shell of a PEP that includes > > abstract and motivation -> hashed out PEP to python-dev -> pronouncement) > > * any changes needed to the issue tracker to help with the workflow? > (stage > > field seems like a failed experiment and we now have several effective > > triage people who can help w/ guiding changes) > > > > If there is something missing from the stdlib discussion that you think > > should be brought up at the summit let me know. And if there is something > > here you want to discuss before the summit let me know and I can start a > > separate thread on it. > > Could you please put these things and the results up on the Python > wiki ?! > > We're going to have a language summit at EuroPython this year > as well and may want to continue/extend the discussion based > on what you're doing at PyCon. > > I expect there will be at least summary emails on what gets discussed. There is also a chance that it will be videotaped. -Brett > Thanks, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 12 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/ > > > ::: 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] topics I plan to discuss at the language summit
On Mon, Jan 11, 2010 at 17:57, Brian Curtin wrote: > On Sun, Jan 10, 2010 at 14:25, Brett Cannon wrote: > >> * any changes needed to the issue tracker to help with the workflow? >> (stage field seems like a failed experiment and we now have several >> effective triage people who can help w/ guiding changes) >> >> -Brett >> > I think it would be interesting to see how people are using the tracker, or > how they want to be using it. For example, there are currently over 1500 > open issues with no stage set, some of which seemingly haven't been read by > anyone at all. Would a properly set stage field save issues from falling > into a black hole? > > "Using" is the key word there. I know this thread went on about how bugs tend to end up being left open, but what I was proposing to talk about was whether there is any shift desired by the seasoned tracker users to help in their work. For instance, the Stage field was meant to help, but I don't think it is really getting used much, which makes it at best just a UI junk and at worst something to confuse new users. So I just wanted to discuss things as a group to see if we could streamline some things, add others, etc. At worst I will try to grab people like Mark D., R. David, Antoine, Georg, etc. at the summit (not sure exactly which the heavy bug closers will be there), take them aside, and flat-out ask what they need to make their jobs easier. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
On Tue, Jan 12, 2010 at 04:29, Michael Foord wrote:
> On 12/01/2010 12:16, Barry Warsaw wrote:
>
> On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
>
>
>
> Actually there's a solution to this one too:
>
>FooBase = Meta('FooBase', (), {})
>class Foo(FooBase):
>...
>
> That should work in Python 2.X and 3.X.
>
>
> Ugly, but good call! :)
>
>
>
>
> There are all sorts of tricks. For example you can do exception handling
> that works with pre-2.6 syntax and 3.0 with a bare except and using
> sys.exc_info. It is horrible, but acceptable for short pieces of code (I
> have a couple of small modules that do this).
>
> I haven't yet tried converting larger code-bases to Python 3, but I think
> the workflow advocated by Martin is greatly preferable to the hacks and
> tricks needed to make the same codebase run under 2 & 3.
>
>
In other words we need to pull together a HOWTO for Python source like the
one for extension modules that Benjamin wrote and make it rather prominently
linked from the Python 3 documentation index page.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] topics I plan to discuss at the language summit
On Tue, 12 Jan 2010 09:47:50 -0800, Brett Cannon wrote: > On Mon, Jan 11, 2010 at 17:57, Brian Curtin wrote: > > On Sun, Jan 10, 2010 at 14:25, Brett Cannon wrote: > >> * any changes needed to the issue tracker to help with the workflow? > >> (stage field seems like a failed experiment and we now have several > >> effective triage people who can help w/ guiding changes) > >> > > I think it would be interesting to see how people are using the tracker, or > > how they want to be using it. For example, there are currently over 1500 > > open issues with no stage set, some of which seemingly haven't been read by > > anyone at all. Would a properly set stage field save issues from falling > > into a black hole? > > > "Using" is the key word there. I know this thread went on about how bugs > tend to end up being left open, but what I was proposing to talk about was > whether there is any shift desired by the seasoned tracker users to help in > their work. For instance, the Stage field was meant to help, but I don't > think it is really getting used much, which makes it at best just a UI junk > and at worst something to confuse new users. So I just wanted to discuss > things as a group to see if we could streamline some things, add others, > etc. Well, I for one find the stage field useful. It reminds me at a glance where the issue is at in the workflow (and 'not set' is a valid place in the workflow that an issue sometimes stays in for a while for reason other than not having been triaged yet). I suspect that if we discussed it as a group (we who make the most changes on the tracker) we could improve it, and the interface in general. By the way, you could talk to people who aren't going to be at the summit on #python-dev; I think all the currently tracker-active people hang out there on a regular basis. I'll have to give some thought to what changes/improvements might be most useful, now that I've been doing this for a while. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] topics I plan to discuss at the language summit
On Tue, Jan 12, 2010 at 10:31, R. David Murray wrote: > On Tue, 12 Jan 2010 09:47:50 -0800, Brett Cannon wrote: > > On Mon, Jan 11, 2010 at 17:57, Brian Curtin > wrote: > > > On Sun, Jan 10, 2010 at 14:25, Brett Cannon wrote: > > >> * any changes needed to the issue tracker to help with the workflow? > > >> (stage field seems like a failed experiment and we now have several > > >> effective triage people who can help w/ guiding changes) > > >> > > > I think it would be interesting to see how people are using the > tracker, or > > > how they want to be using it. For example, there are currently over > 1500 > > > open issues with no stage set, some of which seemingly haven't been > read by > > > anyone at all. Would a properly set stage field save issues from > falling > > > into a black hole? > > > > > "Using" is the key word there. I know this thread went on about how bugs > > tend to end up being left open, but what I was proposing to talk about > was > > whether there is any shift desired by the seasoned tracker users to help > in > > their work. For instance, the Stage field was meant to help, but I don't > > think it is really getting used much, which makes it at best just a UI > junk > > and at worst something to confuse new users. So I just wanted to discuss > > things as a group to see if we could streamline some things, add others, > > etc. > > Well, I for one find the stage field useful. It reminds me at a glance > where the issue is at in the workflow (and 'not set' is a valid place > in the workflow that an issue sometimes stays in for a while for reason > other than not having been triaged yet). I suspect that if we discussed > it as a group (we who make the most changes on the tracker) we could > improve it, and the interface in general. > > By the way, you could talk to people who aren't going to be at the > summit on #python-dev; I think all the currently tracker-active people > hang out there on a regular basis. > > Sounds reasonable. > I'll have to give some thought to what changes/improvements might be > most useful, now that I've been doing this for a while. How about everyone who is active on bugs.python.org give it some thought and we can try to have a discussion at some point in the relatively near future. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] topics I plan to discuss at the language summit
Brett Cannon wrote: > I expect there will be at least summary emails on what gets discussed. > There is also a chance that it will be videotaped. The Wiki makes for a better summary archive though. 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] [RELEASED] Python 2.7 alpha 2
>> a) telling people that they have to move to 2.6 first actually
>> hurts migration, instead of helping, because it implies to them
>> that they have to drop old versions (e.g. 2.3.) - just because
>> they had *always* dropped old versions before supporting new ones.
>
> Is it just an implication, or is it reality?
That's only the implication. However, this was precisely the dialogue
when talking to Django. If you start with "start supporting 2.6", the
immediate response, without listening further, was, "ok, wait until we
drop 2.3, which will be in Spring 2009" (it has happened by now, IIUC).
Then explain it to the individual you are talking to, wait for the next
developer of the project step along, and see how he brings up the
very same line of thinking (supporting new versions == dropping support
for old versions).
I think only part of that comes from the maintenance burden. The other
part is that they *want* to drop support for old versions, so that they
can eventually start using new features (e.g. generator expressions).
So they welcome the requirement to support new versions as an excuse
to drop old ones ("it is obvious that you have to drop 2.3 to support
3.2"). However, their users then won't let them drop old versions.
>
>> b) IMO, people also don't gain much by first migrating to 2.6.
>> In principle, it gives them the opportunity to get py3k warnings.
>> However, I haven't heard a single positive report where these
>> warnings have actually helped people in porting. Yours is the
>> first report saying that you followed the official guideline,
>> but you didn't state whether doing so actually helped (or whether
>> you just ported to 2.6 because the guideline told you to).
>
> Python 2.6 has other useful features, which I want to take advantage of
I think you are a minority with that, being able to actually use the 2.6
features already. Many projects can't, as they have to support at least
2.4 still (so the with statement is right out).
>> Inherently, 2.8 can't improve on that.
>
> I'm not so sure. Yes, as a package maintainer there are older versions to
> think about, but time moves on for everyone (hopefully :). By the time 2.8 is
> released, what will be the minimum version of Python provided by most OS
> vendors (where the majority of Python users probably get their 'python')?
"Current" Linux distributions will have 2.6 then. "Old" installations
will have 2.4.
> I
> guess some people will have to support everything from Python 2.3 to 2.8 but
> you're talking supporting something like a spread of 7 years of Python
> versions. What other platform do you support for 7 years?
I think 2.3 will really be gone by the time 2.8 might get released. Even
with 2.7, you'd end up with a span of seven years, though.
Python had been supporting Windows 95 for more than 7 years (I think
rather 9 or 10), likewise Windows 3.1 before that. Python 2.7 will
likely still support Windows 2000, which then will be ten years old.
Solaris support will probably go back to Solaris 2.6, which will be
13 years old when Python 2.7 gets released.
It's only the Linux (and OS X) releases that move so quickly.
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] [RELEASED] Python 2.7 alpha 2
> Maybe not, but the Distribute feature is there because IMO the > distutils feature by itself isn't particularily useful. You need to > write your own distutils extensions, in practice, and they are not > trivial. I wouldn't say that. My Django port works with bare distutils (as does Django itself), and it works fine. That distribute had to redo it is only because setuptools *replaces* the build_py command, as does the 2to3 support in distutils. So only if you have a different build_py already, you can't use what is in distutils. 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] [RELEASED] Python 2.7 alpha 2
On 12/01/2010 21:53, "Martin v. Löwis" wrote:
a) telling people that they have to move to 2.6 first actually
hurts migration, instead of helping, because it implies to them
that they have to drop old versions (e.g. 2.3.) - just because
they had *always* dropped old versions before supporting new ones.
Is it just an implication, or is it reality?
That's only the implication. However, this was precisely the dialogue
when talking to Django. If you start with "start supporting 2.6", the
immediate response, without listening further, was, "ok, wait until we
drop 2.3, which will be in Spring 2009" (it has happened by now, IIUC).
Then explain it to the individual you are talking to, wait for the next
developer of the project step along, and see how he brings up the
very same line of thinking (supporting new versions == dropping support
for old versions).
I think only part of that comes from the maintenance burden. The other
part is that they *want* to drop support for old versions, so that they
can eventually start using new features (e.g. generator expressions).
So they welcome the requirement to support new versions as an excuse
to drop old ones ("it is obvious that you have to drop 2.3 to support
3.2"). However, their users then won't let them drop old versions.
I agree with Martin that the *perception* is that to use Python 2.6 to
help you port to Python 3 you have to be willing to drop support for
earlier versions of Python.
b) IMO, people also don't gain much by first migrating to 2.6.
In principle, it gives them the opportunity to get py3k warnings.
However, I haven't heard a single positive report where these
warnings have actually helped people in porting. Yours is the
first report saying that you followed the official guideline,
but you didn't state whether doing so actually helped (or whether
you just ported to 2.6 because the guideline told you to).
Python 2.6 has other useful features, which I want to take advantage of
I think you are a minority with that, being able to actually use the 2.6
features already. Many projects can't, as they have to support at least
2.4 still (so the with statement is right out).
Well, the IronPython community has almost completely moved over to
IronPython 2.6. :-)
We tend to ship our Python runtime with our applications though. As it
happens I'm now working with CPython on the server (Python 2.5) and
IronPython in the browser where we are using 2.6. The new property
feature is nice, as is having with without a __future__ import.
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
___
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] [RELEASED] Python 2.7 alpha 2
On Tue, Jan 12, 2010 at 22:56, "Martin v. Löwis" wrote: >> Maybe not, but the Distribute feature is there because IMO the >> distutils feature by itself isn't particularily useful. You need to >> write your own distutils extensions, in practice, and they are not >> trivial. > > I wouldn't say that. My Django port works with bare distutils (as > does Django itself), and it works fine. > > That distribute had to redo it is only because setuptools *replaces* > the build_py command, as does the 2to3 support in distutils. So only > if you have a different build_py already, you can't use what is in > distutils. Yeah, you are right, I misremembered. The actual additional feature is the support for the test command. Testing under Python 2 and 3 without it is annoying. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] [RELEASED] Python 2.7 alpha 2
> [...] >> I've done a fair bit of 3.x porting, and I'm firmly convinced that >> 2.x can do nothing: > [...] >> Inherently, 2.8 can't improve on that. > > I agree that there are limitations like the ones you've listed, but I > disagree with your conclusion. Maybe you assume that it's just as hard > to move to 2.8 (using the py3k backports not available in say 2.5) as it > is to 3.x? Not at all, no. I'd rather expect that code that runs on 2.7 will run on 2.8 unmodified. > But a hypothetical 2.8 would also give people a way to move closer to > py3k without giving up on using all their 2.x-only dependencies. How so? If they use anything that is new in 2.8, they *will* need to drop support for anything before it, no??? > I think it's much more likely that libraries like Twisted can support 2.8 > in the near future than 3.x. Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does that help Twisted in moving to 3.2? > Then, when all of your dependencies (or viable alternatives to those > dependencies) are available for 3.x, you'll have an easier transition if > you can start from a 2.x with fewer differences in features. But you won't *have* fewer differences. Just because your code runs on 2.8 doesn't mean it will stop running on 2.3 (if you have a need for that). This doesn't get you any closer - you can't use any of the 2.8 features as long as you have to support older versions of Python. > Fundamentally the more 2.x can converge on 3.x, the easier it will be > for users to make the leap, because it will be a smaller leap. No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't. > The > longer the 2.x series lives, the more these newer 2.x versions like 2.7 > and maybe even 2.8 will be available on common platforms for people to > depend upon as minimum versions, which means that as time goes by they > can depend on a version that's closer to 3.x. No, that's incorrect. Suppose 2.7 is the last 2.x release, to be released in 2010. Then, in 2015, it may be that everybody has migrated to 2.7, which then is a common platform. If you release 2.8 in 2012, then, in 2015, people will be split between 2.7 and 2.8, and so there won't be a common platform before 2017. So stopping 2.x development *earlier* will also give us a common platform earlier. Regareds, 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] topics I plan to discuss at the language summit
> I think it would be interesting to see how people are using the tracker, > or how they want to be using it. For example, there are currently over > 1500 open issues with no stage set, some of which seemingly haven't been > read by anyone at all. Would a properly set stage field save issues from > falling into a black hole? I personally don't think this would be the case. What would help is people who actually *work* on the issues, rather than merely reading them. However, this being open source, there is no way to force it (unless you create an incentive, such as the five-for-one deal). 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
[Python-Dev] regex module
Hi all, I'm back on the regex module after doing other things and I'd like your opinion on a number of matters: Firstly, the current re module has a bug whereby it doesn't split on zero-width matches. The BDFL has said that this behaviour should be retained by default in case any existing software depends on it. My question is: should my regex module still do this for Python 3? Speaking personally, I'd like it to behave correctly, and Python 3 is the version where backwards-compatibility is allowed to be broken. Secondly, Python 2 is reaching the end of the line and Python 3 is the future. Should I still release a version that works with Python 2? I'm thinking that it could be confusing if new regex module did zero-width splits correctly in Python 3 but not in Python 2. And also, should I release it only for Python 3 as a 'carrot'? Finally, the module allows some extra backslash escapes, eg \g, in the pattern. Should it treat ill-formed escapes, eg \g, as it would have treated them in the re module? Thanks ___ 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] Fwd: Download Page - AMD64
I presume the email below is about the Windows binary. Does the AMD64 release work on intel 64bit and can we make the wording clearer on the download page? The current description is " Windows AMD64 binary". All the best, Michael Original Message Subject:Download Page - AMD64 Date: Fri, 11 Dec 2009 04:03:16 -0600 From: Thomas Brownback To: [email protected] Should I use the AMD64 version of Python on an Intel 64 chip? I know those 64-bit implementations are very similar, but are they similar enough that your AMD64 will work on Intel? If so, perhaps a note should be placed on that page to help avoid confusion. Explicit being better than implicit and all. Thanks for your time, Thomas -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] [RELEASED] Python 2.7 alpha 2
"Martin v. Löwis" wrote: [...] > > But a hypothetical 2.8 would also give people a way to move closer to > > py3k without giving up on using all their 2.x-only dependencies. > > How so? If they use anything that is new in 2.8, they *will* need to > drop support for anything before it, no??? > > > I think it's much more likely that libraries like Twisted can support 2.8 > > in the near future than 3.x. > > Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does > that help Twisted in moving to 3.2? I'm not talking about Twisted moving to 3.x (FWIW, I think the only movement there so far is some patches for some -3 warnings). The situation I'm describing is a project X that: (a) has 2.x-only dependencies, and (b) would like to be as close as possible to 3.x (because they like the new features and/or want to be as ready as possible to jump when (a) is fixed). So just because project X depends on e.g. Twisted, and that Twisted in turn still supports 2.4, doesn't mean that X cannot move to 2.8, and doesn't mean it would get no benefit from doing so. [...] > No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they > likely won't. But this is my point. I think they would as an intermediate step to jumping to 3.x (which also requires dropping 2.5, after all!), if for some reason they cannot yet jump to 3.x, such as a 2.x-only dependency. -Andrew. ___ 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] [RELEASED] Python 2.7 alpha 2
On 1/12/2010 5:04 PM, "Martin v. Löwis" wrote: But you won't *have* fewer differences. Just because your code runs on 2.8 doesn't mean it will stop running on 2.3 (if you have a need for that). This doesn't get you any closer - you can't use any of the 2.8 features as long as you have to support older versions of Python. Fundamentally the more 2.x can converge on 3.x, the easier it will be for users to make the leap, because it will be a smaller leap. No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they likely won't. The longer the 2.x series lives, the more these newer 2.x versions like 2.7 and maybe even 2.8 will be available on common platforms for people to depend upon as minimum versions, which means that as time goes by they can depend on a version that's closer to 3.x. No, that's incorrect. Suppose 2.7 is the last 2.x release, to be released in 2010. Then, in 2015, it may be that everybody has migrated to 2.7, which then is a common platform. If you release 2.8 in 2012, then, in 2015, people will be split between 2.7 and 2.8, and so there won't be a common platform before 2017. Just like people today may need to work with both 2.5 and 2.6, or privately backport 2.6 bugfixes to 2.5. So stopping 2.x development *earlier* will also give us a common platform earlier. With years of bug fixes and hence high quality. ___ 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] regex module
On 1/12/2010 5:10 PM, MRAB wrote: Hi all, I'm back on the regex module after doing other things and I'd like your opinion on a number of matters: Firstly, the current re module has a bug whereby it doesn't split on zero-width matches. The BDFL has said that this behaviour should be retained by default in case any existing software depends on it. My question is: should my regex module still do this for Python 3? Speaking personally, I'd like it to behave correctly, and Python 3 is the version where backwards-compatibility is allowed to be broken. Are you writing a new module with a new name? If so, do you expect it to replace or augment re? (This is the same question as for optparse vs. argparse, which I understand to not yet be decided.) Secondly, Python 2 is reaching the end of the line and Python 3 is the future. Should I still release a version that works with Python 2? I'm thinking that it could be confusing if new regex module did zero-width splits correctly in Python 3 but not in Python 2. And also, should I release it only for Python 3 as a 'carrot'? 2.7 is in alpha with no plans for 2.8, so unless you finish real soon, 2.7 stdlib is already out. A new engine should get some community testing before going in the stdlib. Even 3.2 beta is not that far off (8-9 months?) Do *you* want to do the extra work for a 2.x release on PyPI? Finally, the module allows some extra backslash escapes, eg \g, in the pattern. Should it treat ill-formed escapes, eg \g, as it would have treated them in the re module? What does re do with analogous cases? 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] [RELEASED] Python 2.7 alpha 2
> Nick wrote: >>> This has nothing to do with pushing 3.x, but all with managing >>> available manpower and still providing quality software. >> >> Python 3.x needs more carrots. > > As Guido has said a few times, the gains are far greater for *new* > Python developers than they are for existing ones. Well both you and Guido are most likely 100% correct. :-) > They don't have as rich a 3rd party ecosystem > on Python 3 as they would on Python 2.x at this point in time, but > unlike existing developers they also have the luxury of cherry-picking > just those packages that already have Python 3 support. Most likely. I wouldn't want to say anything to discourage people from going to python 3. In other languages, I have much experience of making the jump to 'a whole new world'. It's unsettling at first, but after that, you suddenly find the new model has a better turbo than the last and you're at the next corner faster than you can think. So it's all good. But I still maintain Python 3.0 needs more carrots. For example, if mercurial or any other cool lib gets added to python 3 (and I can name a few that should go in python 3) then they should be added to python 3 and not to python 2.x They would serve as good carrots. Make fresh the python 3 stdlib and preserve the python 2.x stdlib. I really think we are somewhat short on resources to do what Guido has asked about bringing python up to CPAN level with respect to packages. We're starting a long way back with horses and swords and trying to catch a well fed and greased modern machine.. I'm sure we can get a modern package testbot operational for python. But I wish those who were complaining about the packaging problem so much could throw some money at the problem instead of moaning about it. As is done on other open-source projects. Some organisation would be beneficial. Finding funds so that a small group of people could work on the problem would be a great boost to forward progress. I just think python packaging needs six months of that to repair the years and years of neglect and stagnation. Even if it is only beer and bus fare money. It just needs a temporary shot of adrenalin in the arm.. so to speak.. Regards 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] Fwd: Download Page - AMD64
> I presume the email below is about the Windows binary. Does the AMD64 > release work on intel 64bit and can we make the wording clearer on the > download page? "intel 64bit" is as clear as mud. It could mean the "Intel 64" architecture, or it could mean the "IA-64" architecture, both are 64-bit architectures with processors manufactured by Intel. The former is officially called AMD64 (not by Intel, but officially), and our AMD64 binaries run on such processors. The latter is also called "Itanium", and we stopped producing binaries for that architecture a while ago; the AMD64 binaries will *not* run on it. The wording could probably be changed to match the reader's expectation more, most likely, it would also get more incorrect in the process. To make it correct and explicit, an entire paragraph educating users about 64-bit architectures and that there are many of them and that they are mutually incompatible might be required. Most likely, Thomas' processor implements the AMD64 architecture, even though it is manufactured by Intel. A short sentence that he would probably understand (given that he used "Intel 64", not "64bit") is: """The binaries for AMD64 will also work on processors that implement the Intel 64 architecture (formerly EM64T), i.e. the architecture that Microsoft calls x64, and AMD called x86-64 before calling it AMD64. They will not work on Intel Itanium Processors (formerly IA-64).""" 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] [RELEASED] Python 2.7 alpha 2
> I'm not talking about Twisted moving to 3.x (FWIW, I think the only > movement there so far is some patches for some -3 warnings). The > situation I'm describing is a project X that: > > (a) has 2.x-only dependencies, and > (b) would like to be as close as possible to 3.x (because they like > the new features and/or want to be as ready as possible to jump > when (a) is fixed). This assumes that jumping to 3.x is easier if you are closer to it. Please trust me that this is not the case. >> No, it won't. It might be if people move to 2.8 *and* drop 2.5, but they >> likely won't. > > But this is my point. I think they would as an intermediate step to > jumping to 3.x (which also requires dropping 2.5, after all!), if for > some reason they cannot yet jump to 3.x, such as a 2.x-only dependency. No, and no. No: it's not an intermediate step, and no, supporting 3.x does *not* require dropping 2.5. 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] Fwd: Download Page - AMD64
On 12/01/2010 23:28, "Martin v. Löwis" wrote: [snip...] """The binaries for AMD64 will also work on processors that implement the Intel 64 architecture (formerly EM64T), i.e. the architecture that Microsoft calls x64, and AMD called x86-64 before calling it AMD64. They will not work on Intel Itanium Processors (formerly IA-64).""" To those not intimately aware of the history and present of 64 bit architecture this sentence would be a great addition - thanks. I'm adding it now as a footnote. All the best, Michael Foord 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Fwd: Download Page - AMD64
Michael Foord wrote: > I presume the email below is about the Windows binary. Does the AMD64 > release work on intel 64bit and can we make the wording clearer on the > download page? > > The current description is " Windows AMD64 binary". The installer works on all AMD64 compatible Intel CPUs. *scnr* As you most likely know all modern Intel 64bit CPUs are based on AMD's x86-64 design. Only the Itanium family is based on the other Intel 64bit design: IA-64. The name AMD64 was chosen because most Linux and BSD distributions call it so. The name 'AMD64' has caused confusion in the past because users thought that the installer works only on AMD CPUs. How about: * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / X86-64 binary -- does not include source) instead of: * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does not include source) ? Christia ___ 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] Fwd: Download Page - AMD64
On 12/01/2010 23:40, Michael Foord wrote: On 12/01/2010 23:28, "Martin v. Löwis" wrote: [snip...] """The binaries for AMD64 will also work on processors that implement the Intel 64 architecture (formerly EM64T), i.e. the architecture that Microsoft calls x64, and AMD called x86-64 before calling it AMD64. They will not work on Intel Itanium Processors (formerly IA-64).""" To those not intimately aware of the history and present of 64 bit architecture this sentence would be a great addition - thanks. I'm adding it now as a footnote. I can add it now to the main download page and existing release pages - but are there changes needed to any scripts to change pages created for *new* releases? All the best, Michael Foord All the best, Michael Foord 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] regex module
Terry Reedy wrote:
On 1/12/2010 5:10 PM, MRAB wrote:
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour should be
retained by default in case any existing software depends on it. My
question is: should my regex module still do this for Python 3?
Speaking personally, I'd like it to behave correctly, and Python 3 is
the version where backwards-compatibility is allowed to be broken.
Are you writing a new module with a new name? If so, do you expect it to
replace or augment re? (This is the same question as for optparse vs.
argparse, which I understand to not yet be decided.)
>
It's a module called 'regex'. It can be used in place of 're' by using
"import regex as re", except for differences such as "\g" being a
legal group reference in pattern strings.
Secondly, Python 2 is reaching the end of the line and Python 3 is the
future. Should I still release a version that works with Python 2? I'm
thinking that it could be confusing if new regex module did zero-width
splits correctly in Python 3 but not in Python 2. And also, should I
release it only for Python 3 as a 'carrot'?
2.7 is in alpha with no plans for 2.8, so unless you finish real soon,
2.7 stdlib is already out. A new engine should get some community
testing before going in the stdlib. Even 3.2 beta is not that far off
(8-9 months?) Do *you* want to do the extra work for a 2.x release on PyPI?
Finally, the module allows some extra backslash escapes, eg \g, in
the pattern. Should it treat ill-formed escapes, eg \g, as it would have
treated them in the re module?
What does re do with analogous cases?
The 're' module treats r"\g" as "g"; both 're' and 'regex' treat, say,
r"\q" as "q". The closest analogue to what I'm asking about is that re
treats the ill-formed repeat r"x{1," as a literal, which sort of
suggests that r"\g" should be treated as "g", but r"\g" is now a
group reference (re would treat that as "g". Does that sound
reasonable?
___
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] Fwd: Download Page - AMD64
On 12/01/2010 23:41, Christian Heimes wrote: Michael Foord wrote: I presume the email below is about the Windows binary. Does the AMD64 release work on intel 64bit and can we make the wording clearer on the download page? The current description is " Windows AMD64 binary". The installer works on all AMD64 compatible Intel CPUs. *scnr* As you most likely know all modern Intel 64bit CPUs are based on AMD's x86-64 design. Only the Itanium family is based on the other Intel 64bit design: IA-64. The name AMD64 was chosen because most Linux and BSD distributions call it so. The name 'AMD64' has caused confusion in the past because users thought that the installer works only on AMD CPUs. How about: * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / X86-64 binary -- does not include source) instead of: * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does not include source) Right - I've made that change for the Python 2.6, 2.7, 3.0 and 3.1 download pages with a footnote. Prior to that we were offering ia64 *and* amd64 releases so I've left those unchanged. Thanks, Michael ? Christia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] [RELEASED] Python 2.7 alpha 2
On 12 Jan, 10:04 pm, [email protected] wrote: [...] I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: [...] Inherently, 2.8 can't improve on that. I agree that there are limitations like the ones you've listed, but I disagree with your conclusion. Maybe you assume that it's just as hard to move to 2.8 (using the py3k backports not available in say 2.5) as it is to 3.x? Not at all, no. I'd rather expect that code that runs on 2.7 will run on 2.8 unmodified. But a hypothetical 2.8 would also give people a way to move closer to py3k without giving up on using all their 2.x-only dependencies. How so? If they use anything that is new in 2.8, they *will* need to drop support for anything before it, no??? I think it's much more likely that libraries like Twisted can support 2.8 in the near future than 3.x. Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does that help Twisted in moving to 3.2? I'm not reading this thread carefully enough to make any arguments on either side, but I can contribute a fact. Twisted very likely does not support 2.8 today. I base this on the fact that Twisted does not support 2.7 today, and I expect 2.8 will be more like 2.7 than it will be like 2.3 - 2.6 (which Twisted does support). When I say "support" here, I mean "all of the Twisted unit tests pass on it". Jean-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] [RELEASED] Python 2.7 alpha 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karen Tracey wrote: > On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson wrote: > >> On behalf of the Python development team, I'm gleeful to announce the >> second >> alpha release of Python 2.7. >> >> > Well yay. Django's test suite (1242 tests) runs with just one failure on > the 2.7 alpha 2 level, and that looks to be likely due to the improved > string/float rounding so not really a problem, just a difference. That's > down from 104 failures and 40 errors with 2.7 alpha 1. > > Note on the website page http://www.python.org/download/releases/2.7/ the > "Change log for this release" link is still pointing to the alpha 1 > changelog. Just to add another "success" data point: Zope2's trunk, as well as the 2.12 release, passes all tests (2535 on the trunk) and brings up the appserver just fine under 2.7a2. There is an obnoxious deprecation warning out of the distutils: DeprecationWarning: 'compiler' specifies the compiler type in build_ext. If you want to get the compiler object itself, use 'compiler_obj' which is likely a simple one-line fix, if I only knew what the hell it was whining about. ;) The warning is extra obnoxious because it doesn't tell me what in *my* code triggers the warning (it (needs a 'stacklevel' argument). Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktNNqQACgkQ+gerLs4ltQ7d5gCcCGKVjyOlxnrAln0UnRibS7kd lNIAoIs1RlSGMtJWaY11BqptfDmQvR87 =mIOO -END PGP SIGNATURE- ___ 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] regex module
MRAB wrote: Hi all, I'm back on the regex module after doing other things and I'd like your opinion on a number of matters: Firstly, the current re module has a bug whereby it doesn't split on zero-width matches. The BDFL has said that this behaviour should be retained by default in case any existing software depends on it. My question is: should my regex module still do this for Python 3? Speaking personally, I'd like it to behave correctly, and Python 3 is the version where backwards-compatibility is allowed to be broken. Secondly, Python 2 is reaching the end of the line and Python 3 is the future. Should I still release a version that works with Python 2? I'm thinking that it could be confusing if new regex module did zero-width splits correctly in Python 3 but not in Python 2. And also, should I release it only for Python 3 as a 'carrot'? Finally, the module allows some extra backslash escapes, eg \g, in the pattern. Should it treat ill-formed escapes, eg \g, as it would have treated them in the re module? I've just noticed something odd about the re module: the sub() method doesn't take 'pos' or 'endpos' arguments. search() does; match() does; findall() does(); finditer() does; but sub() doesn't. Maybe there has never been a demand for it. (Nor split(), for that matter.) ___ 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] regex module
On Tue, Jan 12, 2010 at 14:10, MRAB wrote: > Hi all, > > I'm back on the regex module after doing other things and I'd like your > opinion on a number of matters: > > Firstly, the current re module has a bug whereby it doesn't split on > zero-width matches. The BDFL has said that this behaviour should be > retained by default in case any existing software depends on it. My > question is: should my regex module still do this for Python 3? > Speaking personally, I'd like it to behave correctly, and Python 3 is > the version where backwards-compatibility is allowed to be broken. > > If it is a separate module under a different name it can do the proper thing. People will just need to be aware of the difference when they import the module. > Secondly, Python 2 is reaching the end of the line and Python 3 is the > future. Should I still release a version that works with Python 2? I'm > thinking that it could be confusing if new regex module did zero-width > splits correctly in Python 3 but not in Python 2. And also, should I > release it only for Python 3 as a 'carrot'? > > That's totally up to you. There is practically no chance of it getting into the 2.x under the stdlib at this point since 2.7b1 is coming up and this module has not been out in the wild for a year (to my knowledge). If you want to support 2.x that's fine and I am sure users would appreciate it, but it isn't necessary to get into the Python 3 stdlib. > Finally, the module allows some extra backslash escapes, eg \g, in > the pattern. Should it treat ill-formed escapes, eg \g, as it would have > treated them in the re module? > > If you want to minimize the differences then it should probably match. As I said, since it is a different name to import under it can deviate where reasonable, just make sure to clearly document the deviations. -Brett > Thanks > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] Fwd: Download Page - AMD64
> How about: > > * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / > X86-64 binary -- does not include source) > > instead of: > > * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does > not include source) -1. AMD doesn't want us to use the term x86-64 anymore, but wants us to use AMD64 instead. I think we should comply - they invented the architecture, so they have the right to give it a name. Neither Microsoft nor Intel have such a right. 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] Fwd: Download Page - AMD64
On 1/12/2010 2:46 PM, Michael Foord wrote: I presume the email below is about the Windows binary. Does the AMD64 release work on intel 64bit and can we make the wording clearer on the download page? The current description is " Windows AMD64 binary". FWIW, we simply use (64-bit, x64). PlatformDownload == Windows (x86) Windows Installer (MSI) Windows (64-bit, x64) Windows Installer (MSI) https://www.activestate.com/activepython/downloads/ -srid ___ 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] Fwd: Download Page - AMD64
Christian Heimes cheimes.de> writes: > > How about: > > * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / > X86-64 binary -- does not include source) +1. I don't care about trademarks or official names, we should call it whatever is obvious for our users. As for Itanium, it is practically dead, I think there is little chance of people mixing it up with x86-64. cheers 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
