Re: [Python-Dev] User's complaints
On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > Things that struck me as peculiar is the old: > > if __name__ == "__main__": > whatever() > > This is so out of tune with the rest of python it becomes a nuisance. It is not beautiful but very useful. In Python 3000 we can replace it with: @main def whatever(): ... to mark this function as main function if module executed directly. -- bye by Wolfgang ___ 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] User's complaints
On Thu, 13 Jul 2006, Wolfgang Langner wrote: > On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > > Things that struck me as peculiar is the old: > > > > if __name__ == "__main__": > > whatever() > > > > This is so out of tune with the rest of python it becomes a nuisance. > > It is not beautiful but very useful. > In Python 3000 we can replace it with: > > @main > def whatever(): > ... > > to mark this function as main function if module executed directly. Why not simply: def __main__(): ... or even pass in the command-line arguments: def __main__(*args): ... Having to 'import sys' to get at the command-line arguments always seemed awkward to me. 'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged. -- ?!ng ___ 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] User's complaints
On 7/13/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 7/12/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > Thank you very much for your feedback. It helps. With apologies in advance if my own level of understanding is, of course, lacking of advanced constructs. > If it's pure python, why don't people just copy everything under > site-packages after installing? They could/should run compileall > after that to recompile the .pyc files. With 2.5 on 64-bit machines, > C extension modules *must* be recompiled due to lots of internal > changes. I wasn't even aware of the compileall step, can you elaborate since this is the first time I see it being mentioned. > One thing you didn't mention that I've heard from time to time is the > stdlib should be improved. For example, cleaning up old modules. > Though I'm not really sure everyone has the same thing in mind when it > comes to improving the stdlib. How do you envision cleaning up old modules? > Do you think you could help with the doc? How can we get people, > especially tech writers, interested in improving the doc? Most people > agree it's important, but few make time to really improve the doc. > We've talked about making it easier for people to contribute to the > docs, perhaps adding something like a wiki/comments. Do you think > that would help? Wiki/comments are useful, sure, the only problem is that if you have to sift through every single page to spot a useful comment it is not helping. I never liked PHP's comment system to take an example. Personally, but that's just me of course, I prefer a periodic evaluation of comments and reintegration of said comments into the documentation itself. I've been looking at Python's docstrings in the main codebase and that use alone is inconsistent, some areas feature a lot of docstrings, some have none. But with alone docstrings you will not cut it I think. I hope to get around in the coming time to work up some documentation changes/patches and submit these. [if __name__ == "__main__":] > I'm not sure I understand your point. Can you provide more info about > what you dislike/expect instead? Not the above construct at least. :) To me it just feels like a kludge, perhaps due to the fact that the rest of Python just flows from your fingers when writing/programming. Perhaps one could even get away with it in the form of: def __main__(): ...main program... Some other complaints/wishes from a hard core pythonista: - There's no support for real macros. - Writable closures would be nice. - Open classes would be nice. -- Jeroen Ruigrok van der Werven ___ 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] User's complaints
On Jul 13, 2006, at 12:37 AM, Wolfgang Langner wrote:
> On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
>> Things that struck me as peculiar is the old:
>>
>> if __name__ == "__main__":
>> whatever()
>>
>> This is so out of tune with the rest of python it becomes a nuisance.
>
> It is not beautiful but very useful.
> In Python 3000 we can replace it with:
>
> @main
> def whatever():
> ...
>
> to mark this function as main function if module executed directly.
It would probably need to be called something else, because main is
often the name of the main function... but you could write such a
decorator now if you really wanted to.
def mainfunc(fn):
if fn.func_globals.get('__name__') == '__main__':
# ensure the function is in globals
fn.func_globals[fn.__name__] = fn
fn()
return fn
@mainfunc
def main():
print 'this is in __main__'
-bob
___
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] urllib.quote and unicode bug resuscitation attempt
Stefan Rank wrote:
> on 12.07.2006 07:53 Martin v. Löwis said the following:
> > Anthony Baxter wrote:
> >>> The right thing to do is IRIs.
> >> For 2.5, should we at least detect that it's unicode and raise a
> >> useful error?
> >
> > That can certainly be done, sure.
> >
> > Martin
>
> That would be great.
>
> And I agree that updating urllib.quote for unicode should be part of a
> grand plan that updates all of urllib[2] and introduces an irilib /
> urischemes / uriparse module in 2.6 as Martin and John J Lee suggested.
> =)
>
> cheers,
> stefan
Put me down as +1 on raising a useful error instead of a KeyError or whatever,
and +1 on having an irilib, but -1 on working toward accepting unicode in the
URI-oriented urllib.quote(), because (a.) user expectations for strings that
contain non-ASCII-range characters will vary, and (b.) percent-encoding is
supposed to only operate on a byte-encoded view of non-URI information, not
the information itself.
Longer explanation:
I, too, initially thought that quote() was outdated since it choked on unicode
input, but eventually I came to realize that it's wise to reject such input,
because to attempt to percent-encode characters, rather than bytes, reflects a
fundamental misunderstanding of the level at which percent-encoding is
intended to operate.
This is one of the hardest aspects of URI processing to grok, and I'm not
very good at explaining it, even though I've tried my best in the Wikipedia
articles. It's basically these 3 points:
1. A URI can only consist of 'unreserved' characters, as I'm sure you know.
It's a specific set that has varied slightly over the years, and is a subset
of printable ASCII.
2. A URI scheme is essentially a mapping of non-URI information to a sequence
of URI characters. That is, it is a method of producing a URI from non-URI
information within a particular information domain ...and vice-versa.
3. A URI scheme should (though may not do so very clearly, especially the
older it is!) tell you that the way to represent a particular bit of non-URI
information, 'info', in a URI is to convert_to_bytes(info), and then, as per
STD 66, make the bytes that correspond, in ASCII, to unreserved characters
manifest as those characters, and all others manifest as their percent-encoded
equivalents. In urllib parlance, this step is 'quoting' the bytes.
3.1. [This isn't crucial to my argument, but has to be mentioned to complete
the explanation of percent-encoding.] In addition, those bytes corresponding,
in ASCII, to some 'reserved' characters are exempt from needing to be
percent-encoded, so long as they're not being used for their reserved purpose
(if any) in whatever URI component they're going into -- Semantically, there's
no difference between such bytes when expressed in the URI as a literal
reserved character or as a percent-encoded byte. URI scheme specs vary greatly
in how they deal with this nuance. In any case, urllib.quote() has the 'safe'
argument which can be used to specify the exempt reserved characters.
In the days when the specs that urllib was based on were relevant, 99% of the
time, the bytes being 'quoted' were ASCII-encoded strings representing ASCII
character-based non-URI information, so quite a few of us, including many URI
scheme authors, were tempted to think that what was being
'quoted'/percent-encoded *was* the original non-URI information, rather than a
bytewise view of it mandated by a URI scheme. That's what I was doing when I
thought that quote(some_unicode_path) should 'work', especially in light of
Python's "treat all strings alike" guideline. But if you accept all of the
above, which is what I believe the standard requires, then unicode input is a
very different situation from str input; it's unclear whether and how the
caller wants the input to be converted to bytes, if they even understand what
they're doing at all.
See, right now, quote('abc 123%') returns 'abc%20123%25', as you would expect.
Similarly, everyone would probably expect u'abc 123%' to return
u'abc%20123%25', and if we were to implement that, there'd probably be no harm
done.
But look at quote('\xb7'), which, assuming you accept everything I've said
above is correct, rightfully returns '%B7'. What would someone expect
quote(u'\xb7') to return? Some might want u'%B7' because they want the same
result type as the input they gave, with no other changes from how it would
normally be handled. Some might want u'%C2%B7' because they're conflating the
levels of abstraction and expect, say, UTF-8 conversion to be done on their
input. Some (like me) might want a TypeError or ValueError because we
shouldn't be handing such ambiguous data to quote() in the first place. And
then there's the u'\u0100'-and-up input to worry about; what does a user
expect to be done with that?
I would prefer to see quote() always reject unicode input with a TypeError.
Alternatively, if it accepts unicode, it should produce unicode, and since it
ca
Re: [Python-Dev] User's complaints
Ka-Ping Yee wrote: >On Thu, 13 Jul 2006, Wolfgang Langner wrote: > > >>On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: >> >> >>>Things that struck me as peculiar is the old: >>> >>>if __name__ == "__main__": >>>whatever() >>> >>>This is so out of tune with the rest of python it becomes a nuisance. >>> >>> >>It is not beautiful but very useful. >>In Python 3000 we can replace it with: >> >>@main >>def whatever(): >>... >> >>to mark this function as main function if module executed directly. >> >> > >Why not simply: > >def __main__(): >... > >or even pass in the command-line arguments: > >def __main__(*args): >... > >Having to 'import sys' to get at the command-line arguments always >seemed awkward to me. 'import sys' feels like it should be a >privileged operation (access to interpreter internals), and getting >the command-line args isn't privileged. > > +1, seems a lot more elegant than "if __name__ == '__main__'" Regards, -- Aaron Bingham Senior Software Engineer Cenix BioScience GmbH ___ 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] User's complaints
Wolfgang Langner wrote: > @main > def whatever(): > ... This seems like replacing one unpythonic feature with another. (I *still* can't get used to that @ syntax -- it looks like an intruder from Rubyland...) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Aaron Bingham wrote: >Ka-Ping Yee wrote: > > > >>Why not simply: >> >> def __main__(): >> ... >> >>or even pass in the command-line arguments: >> >> def __main__(*args): >> ... >> >>Having to 'import sys' to get at the command-line arguments always >>seemed awkward to me. 'import sys' feels like it should be a >>privileged operation (access to interpreter internals), and getting >>the command-line args isn't privileged. >> >> >> >> >+1, seems a lot more elegant than "if __name__ == '__main__'" > > Just to clarify, I was writing in support of Ping's suggestion of def __main__() or def __main__(*args). The decorator-based solution is ugly. Regards, -- Aaron Bingham Senior Software Engineer Cenix BioScience GmbH ___ 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] Handling of sys.args (Re: User's complaints)
Ka-Ping Yee wrote: > Having to 'import sys' to get at the command-line arguments always > seemed awkward to me. 'import sys' feels like it should be a > privileged operation (access to interpreter internals), and getting > the command-line args isn't privileged. Would it help if sys were pre-imported into the builtins? Or do you think that args shouldn't live in sys at all? Recently I've come to appreciate the ability to get at the args from anywhere, instead of having to catch them from a call to main() and pass them around. So I'd like to still be able to import them from somewhere if I want (doesn't have to be sys, though). And while we're on the subject, anyone think it would be a good idea to drop the silly feature of having the program name as args[0]? You almost *never* want to treat it the same way as the rest of the args, so the first thing you always do is args[1:]. It's not so bad in C, where it's just as easy to start indexing argv from 1 instead of 0. But it makes no sense in Python, IMO. It would be much more sensible to move it into a separate attribute of whatever module we decide to put args in. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Jeroen Ruigrok van der Werven wrote: > - Open classes would be nice. What do you mean by "open classes"? Python classes already seem pretty open to me, by the standards of other languages! -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Armin> On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: >> It is the last point in the first paragraph on time.strftime() >> discussing what changed in Python 2.4 as to what the change was. >> It's also in Misc/NEWS . Basically the guy didn't read the release >> notes or the docs to see why that changed and that it was legitimate >> and needed for stability. Armin> Surely everybody should read and think carefully about each Armin> (longish) NEWS file for each software package whenever they Armin> update their machines or switch to one with newer software than Armin> they last used. I'll add one further point here. I exchanged a couple emails with Greg Black. What happened to him was that some of his customers upgraded their operating systems and got Python 2.4 in the bargain. His software started throwing off errors. At that point he read the NEWS file and saw the problem. He clearly wasn't fully master of the environment in which his customers ran his software, so I think it's understandable that he was caught by surprise by this change. 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
[Python-Dev] Proposal: Add Sudoku Solver To The "this" Module
given that java has beaten us with some 60 bytes:
http://programming.reddit.com/info/9xha/comments/c9y8b
and in order to further improve Python's Kolmogorov rating:
http://en.wikipedia.org/wiki/Kolmogorov_complexity
how about adding Peter Norvig's constraint-based solver to the Python library:
http://www.norvig.com/sudoku.html
?
Anthony ?
("import this;this.suduko()" is 25 characters, and we could always optimize this
a bit more in Python 2.6, if needed).
[\F]
___
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] User's complaints
Neal> I agree, but some of this responsibility has to fall to users. Neal> Sometimes these breakages are bugs, pure and simple. Our tests Neal> don't catch everything. This is why it's really, really important Neal> to get as many alpha/beta testers as possible. Had the issues Neal> been brought up before 2.4 was released, we could have addressed Neal> them. You're of course preaching to the choir here. Somehow we need to do a better job convincing the Python-using public to pay attention to alphas and betas, especially software consultants like Greg Black. Another area where this particular process broke down was that there simply wasn't already a test case for the fairly common case of calling strftime with a six-zeroes pad to format a simple date. Had it been there already, it would have been discovered when Brett added the range checks. 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] User's complaints
On Jul 13, 2006, at 2:02 AM, Greg Ewing wrote: > Jeroen Ruigrok van der Werven wrote: > >> - Open classes would be nice. > > What do you mean by "open classes"? Python > classes already seem pretty open to me, by > the standards of other languages! I'm guessing he's talking about being like Ruby or Objective-C where you can add methods to any other class in the runtime. Basically we'd have that if the built-in classes were mutable, but that just really encourages fragile code. The big problem you run into with open classes is that you end up depending on two libraries that have a different idea of what the "foo" method on string objects should do. Adding open classes would make it easier to develop DSLs, but you'd only be able to reasonably do one per interpreter (unless you mangled the class in a "with" block or something). -bob ___ 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] User's complaints
[EMAIL PROTECTED] wrote: > He clearly wasn't fully master of the environment in which his > customers ran his software, so I think it's understandable that he was > caught by surprise by this change. a programmer that's surprised that code that relies on undocumented behaviour might behave differently if run on a different platform ? *that's* surprising. ___ 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] Proposal: Add Sudoku Solver To The "this" Module
Fredrik Lundh wrote: > given that java has beaten us with some 60 bytes: > and in order to further improve Python's Kolmogorov rating: > how about adding Peter Norvig's constraint-based solver to the Python library: lol! (just waiting for somebody to give a serious explanation on why this is a bad idea!) signature.asc Description: OpenPGP digital 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] User's complaints
Bob Ippolito wrote: >> What do you mean by "open classes"? Python >> classes already seem pretty open to me, by >> the standards of other languages! > > I'm guessing he's talking about being like Ruby or Objective-C where > you can add methods to any other class in the runtime. wouldn't a standard multiargument dispatch mechanism solve this, for most (all?) practical use cases. (and while we're at it, wouldn't a standard multiargument dispatch be nice replacement for the instance-oriented lookup we're using today? dispatching on a single value is so last century ;-) ___ 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] Proposal: Add Sudoku Solver To The "this" Module
"K.S.Sreeram" wrote: > (just waiting for somebody to give a serious explanation on why this is > a bad idea!) \F might have to post this to comp.lang.python first... ___ 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] User's complaints
>> He clearly wasn't fully master of the environment in which his >> customers ran his software, so I think it's understandable that he >> was caught by surprise by this change. Fredrik> a programmer that's surprised that code that relies on Fredrik> undocumented behaviour might behave differently if run on a Fredrik> different platform ? *that's* surprising. Not necessarily. He may not have realized his customers were going to upgrade their operating systems or that the upgrades would involve a new version of Python. Not everyone tracks every Python release. In this case, a) Python 2.4 had been out long enough to turn up in a new (presumably Linux) OS release, and b) since Mr. Black appears to program in Python for a living he should probably have been more attentive to new releases. Maybe Mr. Black hadn't gotten around to testing his software with 2.4 yet. Maybe the software was written on-site for a client and he didn't have access to it to even test in his own environment. 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] User's complaints
Hi Bob, On 7/13/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > Adding open classes would make it easier to develop DSLs, but you'd > only be able to reasonably do one per interpreter (unless you mangled > the class in a "with" block or something). The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). He understands the implications of allowing open classes (import vs. no import changes semantics, etc.). Personally, he doesn't care *too* much about newbie safety since he's not a newbie. To quote verbatim: "give me the big guns :-)" And while we're at it, he also stated: "[...] add multiple dispatch to your list of improvements for Python". I hope this clarifies it a bit for other people. -- Jeroen Ruigrok van der Werven ___ 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] User's complaints
Jeroen Ruigrok van der Werven wrote:
> Hi Bob,
>
> On 7/13/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> Adding open classes would make it easier to develop DSLs, but you'd
>> only be able to reasonably do one per interpreter (unless you mangled
>> the class in a "with" block or something).
>
> The person whose 'complaints' I was stating says that DSLs (Domain
> Specific Languages for those who, like me, were confused about the
> acronym) are a big part of what he is after and one per interpreter is
> fine by him. He also realises that the application(s) he needs them
> for might be unusual. He doesn't specifically need the builtin types
> to be extendable. It's just nice to be able to define a single class
> in multiple modules. Even C++ allows this to some extent (but not as
> much as he'd like).
I'm somewhat confused as to how Python's classes aren't open. Sure, types like
the builtin types that don't have a __dict__ aren't open because there isn't
anywhere to put the extensions, but metaclassing lets you do whatever you want
to any other class:
def extends(orig_cls):
if not hasattr(orig_cls, "__dict__"):
raise TypeError("Cannot extend %r" % cls)
class ExtendMeta(type):
def __new__(mcl, name, bases, ns):
if len(bases) != 1:
raise TypeError("Can only extend single class")
if bases[0] is object:
return type.__new__(mcl, name, bases, ns)
for key, value in ns.iteritems():
if key not in ("__metaclass__", "__dict__"):
setattr(orig_cls, key, value)
return orig_cls
class ExtendCls(object):
__metaclass__ = ExtendMeta
return ExtendCls
>>> class A1(object):
... def method1(self):
... print "Hi, I'm method 1!"
...
>>> class A2(extends(A1)):
... def method2(self):
... print "Hi, I'm method 2!"
...
>>> x = A1()
>>> x.method1()
Hi, I'm method 1!
>>> x.method2()
Hi, I'm method 2!
>>> y = A2()
>>> y.method1()
Hi, I'm method 1!
>>> y.method2()
Hi, I'm method 2!
>>> A1 is A2
True
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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] User's complaints
Nick Coghlan wrote: >> The person whose 'complaints' I was stating says that DSLs (Domain >> Specific Languages for those who, like me, were confused about the >> acronym) are a big part of what he is after and one per interpreter is >> fine by him. He also realises that the application(s) he needs them >> for might be unusual. He doesn't specifically need the builtin types >> to be extendable. It's just nice to be able to define a single class >> in multiple modules. Even C++ allows this to some extent (but not as >> much as he'd like). > > I'm somewhat confused as to how Python's classes aren't open. Sure, types like > the builtin types that don't have a __dict__ aren't open because there isn't > anywhere to put the extensions, but metaclassing lets you do whatever you want > to any other class: you don't even need metaclass trickery to deal with the "define a single class in multiple modules" problem; just use multiple inheritance to bring all the component classes together. ___ 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] Support for PyGetSetDefs in pydoc
Barry Warsaw wrote: > For example, I could change inspect locally so that it gets the type > of datetime.timedelta.days without adding a constant to types.py. Or > I could patch pydoc.py directly and leave even inspect.py out of it. > Or I could create some stupid internal type in some stupid internal > module who's only purpose would be to have a handle on member > descriptors. Or I could change datetime to be built-in. (see what I > mean about levels of ickyness? :). > > I'm up for suggestions. I think this would be worthwhile to address > in Python 2.5 since I think it would be good to have an accurate > representation of Python's built-in types in types.py. Ultimately, I > really care about teaching pydoc.help() about instances of these > types so that users can get better help when they encounter them > (such as might be the case in 3rd party extension modules). > > Suggestions are welcome. Could you include a "look up late-breaking types" function in types.py that site.py calls after it finishes setting up the standard library path? Still a little hackish, I know, but it seems less icky than your suggestions above, as it means that fixing anything similar that comes up in the future will only require modification of types.py. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] User's complaints
Fredrik Lundh wrote: > Nick Coghlan wrote: > >>> The person whose 'complaints' I was stating says that DSLs (Domain >>> Specific Languages for those who, like me, were confused about the >>> acronym) are a big part of what he is after and one per interpreter is >>> fine by him. He also realises that the application(s) he needs them >>> for might be unusual. He doesn't specifically need the builtin types >>> to be extendable. It's just nice to be able to define a single class >>> in multiple modules. Even C++ allows this to some extent (but not as >>> much as he'd like). >> I'm somewhat confused as to how Python's classes aren't open. Sure, types >> like >> the builtin types that don't have a __dict__ aren't open because there isn't >> anywhere to put the extensions, but metaclassing lets you do whatever you >> want >> to any other class: > > you don't even need metaclass trickery to deal with the "define a single > class in multiple modules" problem; just use multiple inheritance to bring > all the component classes together. I didn't mean to say that I thought what I posted was a sensible thing to do - I was mainly curious as to how close I could get to Ruby's class extension syntax by using metaclasses (with the answer being "very", IMO). If someone really wants to extend a Python class, they can just define a function that does what they want and assign it to whatever method names on whatever mutable classes they feel like. No fancy syntax needed :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] User's complaints
Somebody whose name doesn't matter (it's not about him) wrote: > When some of us first saw what PEP 3000 suggested we were thinking: > shit, there goes Python. [...] And later in the same message the same person wrote: > Things that struck me as peculiar is the old: > > if __name__ == "__main__": > whatever() > > This is so out of tune with the rest of python it becomes a nuisance. This is an illustration of the dilemma of maintaining a popular language: Everybody hates change (me too!) but everybody also has one thing that's bothering them so much they absolutely want it to be changed. If you were to implement all those personal pet peeves, you'd get a language that's more different from Python than Python is from Fortran. So where's the middle ground? I believe it's established without a doubt that in biological evolution, changes comes in spurts: A species may change hardly at all for millions of years, and then suddenly, due to not quite understood mechanisms, it starts to change rapidly until a completely new species (or several) has evolved, which again remains stable for a long time. I don't want to adopt this time scale for Python (:-), but I do think it's useful to think of language evolution as a kind of fractal movement -- at every time scale, there are small jumps and the occasional large jump. Python 2.2 was a fairly large jump (new-style classes, iterators, generators, decorators). Python 3000 will be the largest jump so far. There will be larger jumps yet in the distant future. But in between, there will be long periods of (relative) stability. Will it hurt? You bet! But for many species, sooner or later it's evolve or become extinct. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt
on 13.07.2006 10:26 Mike Brown said the following:
> Stefan Rank wrote:
>> on 12.07.2006 07:53 Martin v. Löwis said the following:
>>> Anthony Baxter wrote:
> The right thing to do is IRIs.
For 2.5, should we at least detect that it's unicode and raise a
useful error?
>>> That can certainly be done, sure.
> Put me down as +1 on raising a useful error instead of a KeyError or whatever,
> and +1 on having an irilib, but -1 on working toward accepting unicode in the
> URI-oriented urllib.quote(), because
> See, right now, quote('abc 123%') returns 'abc%20123%25', as you would
> expect.
> Similarly, everyone would probably expect u'abc 123%' to return
> u'abc%20123%25', and if we were to implement that, there'd probably be no
> harm
> done.
Well, originally, I would have expected it to return a byte str(ing),
BUT
I am now converted and think it is best to raise a TypeError for
unicode, and leave the encoding decisions to higher level code.
So I'll repeat the "patch" #1, slightly modified::
if isinstance(s, unicode):
raise TypeError("quote expects an encoded byte string as argument")
Is it safe to assume that code that breaks because of this change was
already broken?
stefan
___
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] Support for PyGetSetDefs in pydoc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2006, at 9:15 AM, Nick Coghlan wrote: > Could you include a "look up late-breaking types" function in > types.py that site.py calls after it finishes setting up the > standard library path? > > Still a little hackish, I know, but it seems less icky than your > suggestions above, as it means that fixing anything similar that > comes up in the future will only require modification of types.py. I've come to the conclusion that it's much better to add a "helper" module that defines a few extension types solely for the purposes of exposing them in types.py, than it is to rely on accidents of implementation discovered in the existing interpreter. To that end, I've implemented a _typesmodule.c that exposes a getset descriptor and a member descriptor on a type that can't be instantiated. That module gets built into Python and provides a central place to add any future C extension types. It also provides a handy place for Jython or IronPython to hang their own equivalents, if and when they ever get them. Then in types.py, we import _types and pull the appropriate types from there. types.py will not define GetSetType or MemberDescriptorType if that module can't be imported so that it's robust for other Python implementations. I like not defining them better than setting them to None in that case. Then inspect.py defines isgetset() and ismemberdescriptor() in terms of those types, but it always returns False if those types don't exist. So inspect.py too is robust for other Python implementations. I've updated SF patch #1520294 and assigned it back to Georg for another quick review. Assuming he likes the updated patch and Anthony approves, please assign it back to me for final checkin. In thinking about this more, re: back porting to Python 2.4, I don't think we can expose GetSetType, MemberDescriptorType, isgetset(), or ismemberdescriptor() in the appropriate modules. That smells too much like the True/False thing. However, I believe I can weedle a fix into pydoc for those types without exposing these new names, so I'd like to do that if there are no objections. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLZw8XEjvBPtnXfVAQLkIAP+O0WXh+xO902KNah/kIYy/GSPsO/CfRUO +YchtF2HdbyEXORwhsLXJVTKVROYgohCQrZp7LUX5vNUah0J0ycIPXhzpqrB0Gmc 8AaRChkFO8EGofzEGOvtunGUGdl9733u2mNUUAhGk15YFs8GDyiuzkL8SitcJQ3q OHnCsdNRuSU= =pbA8 -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] Explicit Lexical Scoping (pre-PEP?)
On 7/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Boris Borcic wrote: > > >> note that most examples of this type already work, if the target type is > >> mutable, and implement the right operations: > >> > >> def counter(num): > >> num = mutable_int(num) > >> def inc(): > >> num += 1 > >> return num > >> return inc > > > > I agree with you (and argued it in "scopes vs augmented assignment vs sets" > > recently) that mutating would be sufficient /if/ the compiler would view > > augmented assignment as mutations operators > > feel free to replace that += with an .add(1) method call; the point > wasn't the behaviour of augmented assigment, the point was that that the > most common use pattern involves *mutation* of the target object. > > the syntax isn't that important, really. Mutation is different from rebinding. A tuple is immutable, but you can rebind the variable that refers to the tuple. I think we will confuse users if we use the term mutation to refer to name binding. Name binding is already a subtle issue, so I think the risk is significant. Jeremy ___ 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] User's complaints
On Jul 13, 2006, at 5:02 AM, Jeroen Ruigrok van der Werven wrote: > Hi Bob, > > On 7/13/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> Adding open classes would make it easier to develop DSLs, but you'd >> only be able to reasonably do one per interpreter (unless you mangled >> the class in a "with" block or something). > > The person whose 'complaints' I was stating says that DSLs (Domain > Specific Languages for those who, like me, were confused about the > acronym) are a big part of what he is after and one per interpreter is > fine by him. He also realises that the application(s) he needs them > for might be unusual. He doesn't specifically need the builtin types > to be extendable. It's just nice to be able to define a single class > in multiple modules. Even C++ allows this to some extent (but not as > much as he'd like). > > He understands the implications of allowing open classes (import vs. > no import changes semantics, etc.). Personally, he doesn't care *too* > much about newbie safety since he's not a newbie. To quote verbatim: > "give me the big guns :-)" > > And while we're at it, he also stated: "[...] add multiple dispatch to > your list of improvements for Python". > > I hope this clarifies it a bit for other people. Well, if this person really weren't a newbie then of course they'd know how to define a metaclass that can be used to extend a (non- built-in) class from another module. They'd probably also know of two or three different implementations of multiple dispatch (or equivalent, such as generic functions) available, and could probably write their own if they had to ;) The only valid complaint, really, is that built-in classes are read- only. I doubt anyone wants to change that. If they want to write things in the style of Ruby, why not just use it? -bob ___ 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] The buffer() function
I just answered a question on comp.lang.python for someone who was asking about how to convert the internal buffer of a ctypes instance into base64 coding, without too much copying: "The conversion calls in the base64 module expect strings as input, so right now I'm converting the binary blocks to strings first, then converting the resulting string to base64. This seems highly inefficient and I'd like to just go straight from binary to a base64 string." Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) and it worked, so that was my answer. As it turns out the guy (unusal!) tried to look up information about the buffer function in the documentation. What he found is this: "Python programmers, trainers, students and bookwriters should feel free to bypass these functions without concerns about missing something important". Not an encouragement to use this function. So, what is the real state of the buffer() function, and the buffer object? IIUC, the buffer object was broken some time ago, but I think it has been fixed. Can the 'status' of the buffer function be changed? To quote the next question from the OP: "Is buffer safe to use? Is there an alternative?" My thinking is that it *is* safe to use, and that there is no alternative (but imo also no alternative is needed). Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Ka-Ping Yee wrote:> Having to 'import sys' to get at the command-line arguments always> seemed awkward to me. 'import sys' feels like it should be a> privileged operation (access to interpreter internals), and getting > the command-line args isn't privileged.Would it help if sys were pre-imported into the builtins?Or do you think that args shouldn't live in sys at all?Recently I've come to appreciate the ability to get at the args from anywhere, instead of having to catch themfrom a call to main() and pass them around. So I'dlike to still be able to import them from somewhereif I want (doesn't have to be sys, though). And while we're on the subject, anyone think it wouldbe a good idea to drop the silly feature of havingthe program name as args[0]? You almost *never* wantto treat it the same way as the rest of the args,so the first thing you always do is args[1:]. It's not so bad in C, where it's just as easy tostart indexing argv from 1 instead of 0. But itmakes no sense in Python, IMO. It would be muchmore sensible to move it into a separate attributeof whatever module we decide to put args in. Makes sense to me. Ruby does this and it makes working with arguments a little bit nicer.-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] The buffer() function
Thomas Heller wrote: > Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) > and it worked, so that was my answer. does ctypes_instance implement the buffer API ? if it does, is the buffer() call even necessary ? ___ 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] The buffer() function
Fredrik Lundh schrieb: > Thomas Heller wrote: > >> Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) >> and it worked, so that was my answer. > > does ctypes_instance implement the buffer API ? if it does, is the > buffer() call even necessary ? Yes, in both cases. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The buffer() function
Thomas Heller wrote: >>> Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) >>> and it worked, so that was my answer. >> >> does ctypes_instance implement the buffer API ? if it does, is the >> buffer() call even necessary ? > > Yes, in both cases. are you sure? does it implement the bf_getreadbuffer slot? afaik, afaicr, and from what I can tell by looking briefly at the sources, the binascii.b2a_base64 function uses the the s# marker, and that argument type accepts strings *and* read only buffers, right away. no extra crud should be necessary. ___ 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] The buffer() function
Fredrik Lundh schrieb: > Thomas Heller wrote: > Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) and it worked, so that was my answer. > >> >>> does ctypes_instance implement the buffer API ? if it does, is the >>> buffer() call even necessary ? >> >> Yes, in both cases. > > are you sure? does it implement the bf_getreadbuffer slot? afaik, > afaicr, and from what I can tell by looking briefly at the sources, the > binascii.b2a_base64 function uses the the s# marker, and that argument > type accepts strings *and* read only buffers, right away. no extra crud > should be necessary. Yes, for binascii.b2a_base64 you are right: bf_getreadbuffer is sufficient. For binascii.b2a_hex (for example), it is not sufficient. But that was not the question. What about the status of the buffer function? All the above functions accept a buffer object. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Community buildbots (was Re: User's complaints)
On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman <[EMAIL PROTECTED]> wrote: >Well here's one I stumbled across the other day. I don't know if it's >legit, but it's still bad PR: > >http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html Having been exhorted (or maybe I mean "excoriated") by your friendly release manager earlier this week to post my comments and criticisms about Python here rather than vent in random IRC chatter, I feel morally compelled to comment. I see some responses to that post which indicate that the specific bug will be fixed, and that's good, but there is definitely a pattern he's talking about here, not just one issue. I think there is a general pattern of small, difficult to detect breakages in Python. Twisted (and the various other Divmod projects that I maintain) are thoroughly unit-tested, but there are still significant issues in each Python release that require changes. Unlike the jerk who posted that "python sucks" rant, I'm not leaving Python because one function changed in a major release; I do expect to have to maintain my projects myself, and major releases are "major" for a reason. I only wish that upgrading all my other dependencies were as easy as upgrading Python! I do see that the developers are working with some caution to avoid breaking code, and attempting to consider the cost of each change. However, although I've seen lots of discussions of what "average" code might break when exposed to new versions of Python, these discussions tend to be entirely hypothetical. Do the core Python developers typically run the test suites of major Python applications when considering major changes, such as Zope, Plone, TurboGears, and of course Twisted? Not that breakages would be considered unacceptable -- some gain is surely worth the cost -- but to establish some empirical level of burden on the community? I would like to propose, although I certainly don't have time to implement, a program by which Python-using projects could contribute buildslaves which would run their projects' tests with the latest Python trunk. This would provide two useful incentives: Python code would gain a reputation as generally well-tested (since there is a direct incentive to write tests for your project: get notified when core python changes might break it), and the core developers would have instant feedback when a "small" change breaks more code than it was expected to. I can see that certain Python developers expect that some of this work is the responsibility of the user community, and to some extent that's true, but at least half of the work needs to be done _before_ the changes are made. If some Python change breaks half of Twisted, I would like to know about it in time to complain about the implementation, rather than flailing around once the Python feature-freeze has set in and hoping that it's nothing too serious. For example, did anyone here know that the new-style exceptions stuff in 2.5 caused hundreds of unit-test failures in Twisted? I am glad the change was made, and one of our users did catch it, so the process isn't fatally broken, but it is still worrying. Another problem is simply that the Python developers don't have the same very public voice that other language developers do. It doesn't necessarily have to be a blog, but python-dev is fast-paced and intimidating, and a vehicle for discussion among those in the know, rather than dissimenation to the community at large. It's a constant source of anxiety to me that I might miss some key feature addition to Python which breaks or distorts some key bit of Twisted functionality (as the new-style exceptions, or recent ImportWarning almost did) because I don't have enough time to follow all the threads here. I really appreciate the work that Steve Bethard et. al. are doing on the python-dev summaries, but they're still pretty dry and low level. While the new python.org is very nice, I do note that there's no "blogs" entry on the front page, something which has become a fixture on almost every other website I visit regularly. The news page is not very personal, mainly a listing of releases and events. There's no forum for getting the community _excited_ about new features (especially new features which are explicitly enabled by potential breakages), and selling them on the cool uses. Who knows, maybe I'll even start using decorators syntax all over the place if I see them presented somewhere by someone who is very excited about the feature and thinks it's worthwhile, rather than as a defense on a mailing list against a criticism, or a simple announcement of the feature's existence. I've seen the other side of this problem as well, so I can appreciate that it is quite difficult to get this kind of thing right: lots of applications using Twisted break when we change broken or deprecated APIs. Twisted is lucky though; it has numerous subprojects, and I maintain a half-dozen unrelated projec
Re: [Python-Dev] Community buildbots
No real time to respond in detail here, but one small comment. [EMAIL PROTECTED] writes: > I see some responses to that post which indicate that the specific bug will be > fixed, and that's good, but there is definitely a pattern he's talking about > here, not just one issue. I think there is a general pattern of small, > difficult to detect breakages in Python. Remember these words... > For example, did anyone here know that the new-style exceptions stuff in 2.5 > caused hundreds of unit-test failures in Twisted? I am glad the change was > made, and one of our users did catch it, so the process isn't fatally broken, > but it is still worrying. When implementing this stuff, I could have merely made it possible for exceptions to be new-style, and left the builtin exceptions as classic classes. This didn't seem to be an especially good idea, as it would leave code working _most_ of the time, only to break horribly when confronted with a rare new-style exception. So I made the decision (and I don't think I ever got around to explicitly discussing this with anyone, nor if the people who actually updated my patch and checked it in thought about it at all) to make the built in exceptions new-style, precisely to make it a screamingly obvious change. I didn't _know_ when I was doing it that I'd break Twisted unit tests, but I was hardly a surprise. I think the idea of a buildbot running various projects tests suites with svn HEAD is a great idea -- back when I was doing 2.2.1 I did run a few third party test suites (zodb comes to mind) but as always with these things, automation is a good idea. Cheers, mwh -- > Why are we talking about bricks and concrete in a lisp newsgroup? After long experiment it was found preferable to talking about why Lisp is slower than C++... -- Duane Rettig & Tim Bradshaw, comp.lang.lisp ___ 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] The buffer() function
Thomas Heller <[EMAIL PROTECTED]> wrote: > But that was not the question. What about the status of the buffer function? >From what I understand, it is relatively safe as long as you don't mutate an object while there is a buffer attached to it. That is: import array a = array.array(...) b = buffer(a) for i in xrange(...): a.extend(a[:]) print str(b) ... may cause you some problems (the a[:] bit was to pointer movement movement on realloc). Those problems will depend on your platform. - Josiah ___ 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] Community buildbots (was Re: User's complaints)
On Thu, Jul 13, 2006, [EMAIL PROTECTED] wrote: > > I would like to propose, although I certainly don't have time to > implement, a program by which Python-using projects could contribute > buildslaves which would run their projects' tests with the latest > Python trunk. This would provide two useful incentives: Python code > would gain a reputation as generally well-tested (since there is a > direct incentive to write tests for your project: get notified when > core python changes might break it), and the core developers would > have instant feedback when a "small" change breaks more code than it > was expected to. There's been some recent discussion in the PSF wondering where it would make sense to throw some money to remove grit in the wheels; do you think this is a case where that would help? -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ 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] Community buildbots (was Re: User's complaints)
On Thu, Jul 13, 2006 at 02:03:22PM -0400, [EMAIL PROTECTED] wrote: > I would like to propose, although I certainly don't have time to implement, > a program by which Python-using projects could contribute buildslaves which > would run their projects' tests with the latest Python trunk. An excellent idea! > It's a constant source of anxiety to me > that I might miss some key feature addition to Python which breaks > or distorts some key bit of Twisted functionality (as the new-style > exceptions, or recent ImportWarning almost did) because I don't have > enough time to follow all the threads here. So don't read threads -- just try the alphas and betas! The "What's New" documents have a 'porting' section that flags changes that may require application changes, but items are added only if I think of them or if someone suggests them (e.g. generator.gi_frame can be None in Python 2.5 -- I would never have thought people would have code that broke because of this). > While the new python.org is very nice, I do note that there's no "blogs" > entry > on the front page, something which has become a fixture on almost every > other website I visit regularly. A 'Blogs' link could be trivially added by linking to planet.python.org, though the blogs collected there are not in any way 'the Python developers', but a jumble of developers and users. I don't think enough core developers have weblogs (or write about Python) to make a 'python-dev only' planet very useful. > mainly a listing of releases and events. There's no forum for getting the > community _excited_ about new features (especially new features which are > explicitly enabled by potential breakages), and selling them on the cool > uses. I think the venue for this would be weblog entries or news sites such as oreillynet.com. I do worry that we don't have enough people writing articles and things, but have no idea how to encourage people to write more. --amk ___ 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] The buffer() function
On Jul 13, 2006, at 12:52 PM, Thomas Heller wrote: > IIUC, the buffer object was broken some time ago, but I think it has > been fixed. Can the 'status' of the buffer function be changed? > To quote the next question from the OP: > > "Is buffer safe to use? Is there an alternative?" > > My thinking is that it *is* safe to use, and that there is > no alternative (but imo also no alternative is needed). I believe it's safe, except when used on an array.array object. However, that's not buffer's fault, but rather a bug in the array class. The buffer interface requires that, as long as a reference to a python object is alive, pointers into its buffer will not become invalidated. Array breaks that guarantee. To fix this, array ought to make a sub-object that this guarantee _does_ hold for. And when it needs more storage, simply make a new sub-object with more storage. Then, the buffer's reference would be to the refcounted sub-object, and thus the associated memory wouldn't go away until the buffer was done with it. James ___ 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] Handling of sys.args (Re: User's complaints)
On Thu, 13 Jul 2006, Greg Ewing wrote: > Would it help if sys were pre-imported into the builtins? > Or do you think that args shouldn't live in sys at all? I feel like the command-line arguments don't really belong in sys, and i'd rather not have 'sys' pre-imported into the builtins. I think of 'sys' as the place for sensitive interpreter internals and the builtins as the place for harmless functions. They're at opposite ends of the scale -- 'sys' is the most privileged; builtins are the least privileged. From a security point of view, 'import' is the main way to get dangerous new functionality. I realize 'open' breaks this concept, but it's nice to be able to say, to a rough approximation, that preventing 'import' gives you an interpreter that can do computations but isn't a security risk. These are just my feelings -- i'm not sure how consistent this is with the original intent of 'sys'. I think it would be a quite useful distinction to have, though. > And while we're on the subject, anyone think it would > be a good idea to drop the silly feature of having > the program name as args[0]? You almost *never* want > to treat it the same way as the rest of the args, > so the first thing you always do is args[1:]. Starting the args array with the first argument (and putting the program name somewhere else) seems Pythonic to me. -- ?!ng ___ 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] The buffer() function
Josiah Carlson schrieb: > Thomas Heller <[EMAIL PROTECTED]> wrote: >> But that was not the question. What about the status of the buffer function? > >>From what I understand, it is relatively safe as long as you don't > mutate an object while there is a buffer attached to it. > > That is: > > import array > a = array.array(...) > b = buffer(a) > for i in xrange(...): > a.extend(a[:]) > print str(b) > > ... may cause you some problems (the a[:] bit was to pointer movement > movement on realloc). Those problems will depend on your platform. AFAIK, the buffer object now does not hold a pointer into the object it has been constructed from, it only gets it when its needed. IMO Objects/bufferobject.c, revision 35400 is considered safe. The checkin comment (by nascheme) was, more than 2 years ago: "Make buffer objects based on mutable objects (like array) safe." Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/13/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Thu, 13 Jul 2006, Greg Ewing wrote: > > Would it help if sys were pre-imported into the builtins? > > Or do you think that args shouldn't live in sys at all? > > I feel like the command-line arguments don't really belong in sys, > and i'd rather not have 'sys' pre-imported into the builtins. > > I think of 'sys' as the place for sensitive interpreter internals > and the builtins as the place for harmless functions. They're at > opposite ends of the scale -- 'sys' is the most privileged; > builtins are the least privileged. From a security point of view, > 'import' is the main way to get dangerous new functionality. > I realize 'open' breaks this concept, but it's nice to be able to > say, to a rough approximation, that preventing 'import' gives you > an interpreter that can do computations but isn't a security risk. > > These are just my feelings -- i'm not sure how consistent this is > with the original intent of 'sys'. I think it would be a quite > useful distinction to have, though. sys is a grab-bag. Note that it also has a good deal of harmless read-only data: maxint, version, platform and many more. But it seems to specialize in things that you may modify to change global behavior: path, modules, stdout, ps1, displayhook and others. I'nm afraid if we were to split it by functionality we'd have to split it 5-way or so... > > And while we're on the subject, anyone think it would > > be a good idea to drop the silly feature of having > > the program name as args[0]? You almost *never* want > > to treat it the same way as the rest of the args, > > so the first thing you always do is args[1:]. > > Starting the args array with the first argument (and putting > the program name somewhere else) seems Pythonic to me. As long as it's called args, not argv, I agree. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The buffer() function
Thomas Heller <[EMAIL PROTECTED]> wrote: > AFAIK, the buffer object now does not hold a pointer into the object > it has been constructed from, it only gets it when its needed. > > IMO Objects/bufferobject.c, revision 35400 is considered safe. > > The checkin comment (by nascheme) was, more than 2 years ago: > "Make buffer objects based on mutable objects (like array) safe." It's good to hear that bug has been squished. I believe buffer() is generally safe then, according to my somewhat limited experience in its use and knowledge about its implementation. - Josiah ___ 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] Handling of sys.args (Re: User's complaints)
On systems that are not Unix-derived (which, nowadays, are rare), there is commonly no such thing as a program name in the first place. It is possible to get into that state on some Unices - i.e. ones which have a form of exec that takes a file descriptor, inode number or whatever. This is another argument for separating off argv[0] and allowing the program name to be None if there IS no program name. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Community buildbots (was Re: User's complaints)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2006, at 2:03 PM, [EMAIL PROTECTED] wrote: > Having been exhorted (or maybe I mean "excoriated") by your > friendly release > manager earlier this week to post my comments and criticisms about > Python here > rather than vent in random IRC chatter, I feel morally compelled to > comment. And I'm glad you did because you made some excellent comments. > However, although I've seen lots of discussions of what "average" > code might > break when exposed to new versions of Python, these discussions > tend to be > entirely hypothetical. Do the core Python developers typically run > the test > suites of major Python applications when considering major changes, > such as > Zope, Plone, TurboGears, and of course Twisted? Not that breakages > would be > considered unacceptable -- some gain is surely worth the cost -- > but to > establish some empirical level of burden on the community? I do plan on very soon running Mailman's meager test suite and running more manual functional tests on Python 2.5b2. Compared to Twisted, Mailman is pretty simple and doesn't do that much fancy stuff so I suspect that it'll mostly work, but you never know until you try it. I'd support adding Mailman to a community buildbot army, although I don't personally have the cycles to build out such a beast. I also plan on testing my Real Job's embedded application against Python 2.5b2 sometime this week or next. We're on Python 2.4.2 atm and that is much more complicated because of all the C API we use. I'm less sanguine about breakage there, but I'll post here if I find anything egregious (fortunately, we have an extensive test suite to rely upon). > Twisted itself is a fairly > representative "application using Twisted", so when something > breaks "average" > Twisted code, I know about it right away. Python is less an > application using > Python: the standard library is rather passive (there is no "end-to- > end" > application path to test, only individual functions and classes), > and the test > coverage of included Python modules is rather spotty. This really is an excellent point and makes me think that we may want to consider elaborating on the Python release cycle to include a gamma phase or a longer release candidate cycle. OT1H I think there will always be people or projects that won't try anything until the gold release, and that if we've broken anything in their code we simply won't know it until after that, no matter how diligent we are. OTOH, a more formal gamma phase would allow us to say "absolutely no changes are allowed now unless it's to fix backward compatibility". No more sneaking in new sys functions or types module constants during the gamma phase. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLanoHEjvBPtnXfVAQJB6gP/SwVtejenN0/7tszePbJ4O20l98k2Z/7N rs9dfF2+Jcy/OLzSCcW/OW4iVf+iPJMWUNqHEPFDQO/+nVifh8pjjWGTQJMc8ynm 7HNCk/ZciZyNqeGbmGvzHoywmrldbDPkx5Y6Fo13yel0slw2Qo6gC6W8aygi7giP boJiovnaKH0= =wRxy -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
[Python-Dev] Partial support for dlmodule.c in 64-bits OSes
Currently, many 64-bits Oses cannot uses the dlmodule due to the conflicts
between the sizes of int, long and char *. That is well. The check is made as
run-time, which is also very well.
The problem is that the Python configuration script (setup.py) also makes the
check and plainly excludes dlmodule.c from being built and deployed. That is not
so well.
The reason is that we use the dlmodule solely to get access to the various flags
(RTLD_NOW, RTLD_GLOBAL, etc), so that we can do some magic with loaded shared
libraries, such as over-ridding the import mechanism so that the default load
flags get changed (via sys.setdlopenflags()) to force some semantics.
Currently this doesn't work on most 64-bits OSes because the dl module doesn't
exists, so it cannot be imported and its RTLD_* symbols are not accessible.
So I ask if it would be possible that the test for sys.maxint == 0x7fff in
setup.py be dropped in future releases.
Here's a relevant diff from the current setup.py in SVN:
1025,1030c1025,1029
+ # This requires sizeof(int) == sizeof(long) == sizeof(char*)
+ # but it will be tested at run-time: give access to the dl module so
+ # that RTDL_* symbols can be accessed.
+ dl_inc = find_file('dlfcn.h', [], inc_dirs)
+ if (dl_inc is not None) and (platform not in ['atheos']):
+ exts.append( Extension('dl', ['dlmodule.c']) )
---
- if sys.maxint == 0x7fff:
- # This requires sizeof(int) == sizeof(long) == sizeof(char*)
- dl_inc = find_file('dlfcn.h', [], inc_dirs)
- if (dl_inc is not None) and (platform not in ['atheos']):
- exts.append( Extension('dl', ['dlmodule.c']) )
___
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] Community buildbots
On Thu, 13 Jul 2006 19:19:08 +0100, Michael Hudson <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: >> For example, did anyone here know that the new-style exceptions stuff in 2.5 >> caused hundreds of unit-test failures in Twisted? I am glad the change was >> made, and one of our users did catch it, so the process isn't fatally broken, >> but it is still worrying. > >When implementing this stuff, I could have (... snip ...) To be clear, I agree with the decision you made in this particular case. I just would have appreciated the opportunity to participate in the discussion before the betas were out and the featureset frozen. (Of course I *can* always do that, and some other Twisted devs watch python-dev a bit more closely than I do, but the point is that the amount of effort required to do this is prohibitive for the average Python hacker, whereas the time to set up an individual buildbot might not be.) (Aside: IMHO, the sooner we can drop old-style classes entirely, the better. That is one bumpy Python upgrade process that I will be _very_ happy to do. There's no way to have documentation that expresses the requirement that an implementation of an interface be new-style or old-style without reference to numerous historical accidents, which are bewildering and upsetting to people reading documentation for the first time.) ___ 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] Community buildbots (was Re: User's complaints)
Barry Warsaw wrote: > OTOH, a more formal gamma phase would allow us to say > "absolutely no changes are allowed now unless it's to fix backward > compatibility". No more sneaking in new sys functions or types > module constants during the gamma phase. This is pretty common in project management. For instance, GCC has a rather complex 4-stage release process, whose last phase (beginning at the point the release is branched in SVN) is made of commits only for regressions. -- Giovanni Bajo ___ 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] Community buildbots
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On Thu, 13 Jul 2006 19:19:08 +0100, Michael Hudson <[EMAIL PROTECTED]> wrote:>[EMAIL PROTECTED] writes:>> For example, did anyone here know that the new-style exceptions stuff in 2.5>> caused hundreds of unit-test failures in Twisted? I am glad the change was>> made, and one of our users did catch it, so the process isn't fatally broken,>> but it is still worrying. >>When implementing this stuff, I could have (... snip ...)To be clear, I agree with the decision you made in this particular case. Ijust would have appreciated the opportunity to participate in the discussion before the betas were out and the featureset frozen. (Of course I*can* always do that, and some other Twisted devs watch python-dev a bit moreclosely than I do, but the point is that the amount of effort required to do this is prohibitive for the average Python hacker, whereas the time to set up anindividual buildbot might not be.)One way to try to track python-dev is the python-dev Summaries. While Steven is only human and thus cannot always get them out immediately, they do happen frequently enough that major decisions will be covered before betas are hit. -Brett(Aside: IMHO, the sooner we can drop old-style classes entirely, the better. That is one bumpy Python upgrade process that I will be _very_ happy to do.There's no way to have documentation that expresses the requirement that animplementation of an interface be new-style or old-style without reference to numerous historical accidents, which are bewildering and upsetting to peoplereading documentation for the first time.)___Python-Dev mailing list [email protected]://mail.python.org/mailman/listinfo/python-devUnsubscribe: 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] Community buildbots
[EMAIL PROTECTED] wrote: > (Aside: IMHO, the sooner we can drop old-style classes entirely, the > better. > That is one bumpy Python upgrade process that I will be _very_ happy > to do. I think python should have a couple more of future imports. "from __future__ import new_classes" and "from __future__ import unicode_literals" would be really welcome, and would smooth the Py3k migration process -- Giovanni Bajo ___ 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] Community buildbots
On 7/13/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > I think python should have a couple more of future imports. "from __future__ > import new_classes" and "from __future__ import unicode_literals" would be > really welcome, and would smooth the Py3k migration process Along similar lines as glyph, after complaining about this for a long time "offline" with my friends, I decided it's probably a good idea to get involved and vote that the __future__ import for unicode_literals be implemented. python -U is a failure for obvious reasons and a __future__ import is clearly better. Does anyone want to pair on this? -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
On Jul 13, 2006, at 1:53 PM, Giovanni Bajo wrote: > [EMAIL PROTECTED] wrote: > >> (Aside: IMHO, the sooner we can drop old-style classes entirely, the >> better. >> That is one bumpy Python upgrade process that I will be _very_ happy >> to do. > > I think python should have a couple more of future imports. "from > __future__ > import new_classes" and "from __future__ import unicode_literals" > would be > really welcome, and would smooth the Py3k migration process "from __future__ import new_classes" exists, but the syntax is different: __metaclass__ = type -bob ___ 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] Community buildbots (was Re: User's complaints)
On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote: >There's been some recent discussion in the PSF wondering where it would >make sense to throw some money to remove grit in the wheels; do you think >this is a case where that would help? Most likely yes. It's not a huge undertaking, and there are a lot of people out there in the community with the knowledge of Buildbot to make this happen. ___ 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] Community buildbots (was Re: User's complaints)
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote: > > >There's been some recent discussion in the PSF wondering where it would > >make sense to throw some money to remove grit in the wheels; do you think > >this is a case where that would help? > > Most likely yes. It's not a huge undertaking, and there are a lot of people > out > there in the community with the knowledge of Buildbot to make this happen. I'm at least willing to set up the buildbots for projects I care about (Twisted, pydoctor, whatever), and perhaps help out with the setting up the buildmaster. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Fredrik Lundh wrote: > (and while we're at it, wouldn't a standard multiargument dispatch be > nice replacement for the instance-oriented lookup we're using today? > dispatching on a single value is so last century ;-) That's highly debatable, and as I'm sure you remember, has been highly debated. :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Jeroen Ruigrok van der Werven wrote: > It's just nice to be able to define a single class > in multiple modules. It *seems* nice until you want to track down which source file the definition of some method comes from. Those used to the "one huge global namespace" of C and C++ likely don't see this as a problem. But since I've come to appreciate the benefits of Python's module system, I don't want to go back to that nightmare. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Jeroen Ruigrok van der Werven wrote: >> It's just nice to be able to define a single class >> in multiple modules. Greg> It *seems* nice until you want to track down which Greg> source file the definition of some method comes Greg> from. Greg> Those used to the "one huge global namespace" of Greg> C and C++ likely don't see this as a problem. But Greg> since I've come to appreciate the benefits of Greg> Python's module system, I don't want to go back Greg> to that nightmare. While I think there are good arguments both ways, I don't think that finding source definitions of methods or classes counts as one - let alone as a nightmare. Tools like tags (in vi and emacs and lisp environments) work quickly and accurately, are easy to use (one keystroke in vi and M-. or similar in emacs to go to a defn, and then a tags pop to come back), work in an identical way on many source languages, and they have been around for literally decades. That's to say nothing of IDE or CASE tools that support finding definitions, callers, etc. Regards, Terry ___ 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] Community buildbots (was Re: User's complaints)
On Thursday 13 July 2006 16:05, Barry Warsaw wrote: > This really is an excellent point and makes me think that we may want > to consider elaborating on the Python release cycle to include a > gamma phase or a longer release candidate cycle. OT1H I think there ... > "absolutely no changes are allowed now unless it's to fix backward > compatibility". No more sneaking in new sys functions or types > module constants during the gamma phase. +42 It feels like the release cycle from alpha1 to final has gotten increasingly rushed. While I'm sure some of that is just me having my attention elsewhere, I suspect a longer tail on the cycle to do gammas (or release candidates, or whatever) would definately encourage more testing with applications and the larger frameworks. No, it won't catch everything, but I think it would help. -Fred -- Fred L. Drake, Jr. ___ 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] User's complaints
On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
>
> > If it's pure python, why don't people just copy everything under
> > site-packages after installing? They could/should run compileall
> > after that to recompile the .pyc files. With 2.5 on 64-bit machines,
> > C extension modules *must* be recompiled due to lots of internal
> > changes.
>
> I wasn't even aware of the compileall step, can you elaborate since
> this is the first time I see it being mentioned.
python -mcompileall -h
It's in the stdlib. It is used by the build process to recursively
traverse directories and compile all the .py files into .pyc (or .pyo)
files. So if you wanted to copy everything from site-package in 2.4
to 2.5, you could do something like:
cp -r /usr/lib/python2.{4,5}/site-packages
/usr/bin/python2.5 -mcompileall -d /usr/lib/python2.5/site-packages
That should really be all that's required. It of course doesn't verify
the packages are correct or that you still want to keep all the files.
This generally works for .so's too. However a warning will be
generated each time you import the .so since it was built on an old
version of Python.. On 2.5 in 64-bit systems, this will definitely
not work.
> > One thing you didn't mention that I've heard from time to time is the
> > stdlib should be improved. For example, cleaning up old modules.
> > Though I'm not really sure everyone has the same thing in mind when it
> > comes to improving the stdlib.
>
> How do you envision cleaning up old modules?
For me, manually. Do you still need moduleX? There's no way for a
computer to tell you the answer, it depends on what you will use with
the new version of Python.
n
___
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] Community buildbots (was Re: User's complaints)
FWIW, I tend to run a few project(*) test suites when doing minor releases (2.x.y), just to make sure I don't break things. For major releases, it's a fair bit more work - something like Twisted or Zope3 play at such a low level with the Python interfaces that there's nearly always breakages or massive warning dumps (from memory, zope.interface uses 'with' as an argument name, a lot). The "community buildbot" idea is a good one, although it should just be possible to write something for buildbot that checks out and builds the latest Python SVN, then installs it to a temporary location, then adds that location to the front of the path. Then each project could just add a "Python SVN buildbot" to their exists bbot install. Anthony (*) Typically includes Zope3 and Twisted, because I have these just lying around. ___ 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] Community buildbots
glyph> *can* always do that, and some other Twisted devs watch glyph> python-dev a bit more closely than I do, but the point is that glyph> the amount of effort required to do this is prohibitive for the glyph> average Python hacker, whereas the time to set up an individual glyph> buildbot might not be.) If you're concerned about noticing when a new release train is pulling out of the station I think it would be sufficient to subscribe to the low-volume python-announce mailing list. You will see announcements about alphas and betas there. Even lower volume would be a subscription to the RSS feed of Python announcements on the python.org front page (scroll to the bottom). The buildbot idea sounds excellent. 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] Community buildbots (was Re: User's complaints)
Fred> It feels like the release cycle from alpha1 to final has gotten Fred> increasingly rushed. Same here. I believe there was some shortening of the 2.5 release cycle two or three months ago. I don't recall why or by how much, but I think the acceleration has resulted in a lot of the "can't we please squeeze this one little change in?" that's been happening. Shortening a micro release a bit seems reasonably easy to accommodate, but since minor releases occur so infrequently, I think it would be better to stretch them out if necessary. 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] Handling of sys.args (Re: User's complaints)
Ka-Ping Yee wrote: > I think of 'sys' as the place for sensitive interpreter internals Well, it seems to be rather a mixture at the moment. I suppose you could regard sys.modules as fairly sensitive, since messing with it can have big effects on the behaviour of the whole program, and changing sys.stdout or sys.stderr also has global effects. But it's also how you do things like getting info about the current exception, which doesn't seem particularly sensitive to me. Maybe sys needs to be split into two modules, with the non-sensitive one pre-imported (so that the importless interpreter you suggest wouldn't be unnecessarily crippled). -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Guido van Rossum wrote: > I'nm afraid if we > were to split it by functionality we'd have to split it 5-way or so... What about just splitting it into "mutable" and "immutable" parts? That would be a fairly clear division, I think. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Nick Maclaren wrote: > On systems that are not Unix-derived (which, nowadays, are rare), > there is commonly no such thing as a program name in the first place. > It is possible to get into that state on some Unices - i.e. ones which > have a form of exec that takes a file descriptor, inode number or > whatever. I don't think that applies to the Python args[] though, since its args[0] isn't the path of the OS-level executable, it's the path of the main Python script. But you could still end up without one, if the main script comes from somewhere other than a file. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
On Thu, 13 Jul 2006 23:27:56 -0500, [EMAIL PROTECTED] wrote: >The buildbot idea sounds excellent. Thanks. If someone can set this up, it pretty much addresses my concerns. >If you're concerned about noticing when a new release train is pulling out >of the station I think it would be sufficient to subscribe to the low-volume >python-announce mailing list. You will see announcements about alphas and >betas there. Even lower volume would be a subscription to the RSS feed of >Python announcements on the python.org front page (scroll to the bottom). I am aware of when new releases come out :). What I'm not aware of is what features (may) have broken my code, and why. As long as Python's [EMAIL PROTECTED] continues to run the test suites cleanly, I am mostly unconcerned. When it breaks, though, I want a chance to look at the cause of the breakage, *before* there is an alpha or beta Python release out and people are starting to write code that depends on its new features. Most importantly, python-dev is extremely context-sensitive. I want to be able to participate in the discussion when my concerns are relevant and still reasonable to act upon. Additionally I would like to know about these changes so that I can modify code to support Python releases and release a compatible version of Twisted _in advance_ of the Python release that's going to break them, so assuming users are keeping relatively current, there won't be a window where their most recent Twisted release will not work with the most recent Python release. ___ 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] Community buildbots
Giovanni Bajo wrote: > [EMAIL PROTECTED] wrote: > > I think python should have a couple more of future imports. "from __future__ > import new_classes" and "from __future__ import unicode_literals" would be > really welcome, and would smooth the Py3k migration process Actually - can we make new-style classes the default, but allow a way to switch to old-style classes if needed? Perhaps a command-line argument to set the default back to old-style? -- Talin ___ 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] Community buildbots (was Re: User's complaints)
Barry Warsaw wrote: > we may want > to consider elaborating on the Python release cycle to include a > gamma phase or a longer release candidate cycle. Maybe there could be an "unstable" release phase that lasts for a whole release cycle. So you'd first release version 2.n as "unstable", and keep 2.(n-1) as the current "stable" release. Then when 2.(n+1) is ready, 2.n would become "stable" and 2.(n+1) would become the new "unstable". (Feel free to substitute other terms for "stable" and "unstable" if you don't like them.) That would give people plenty of warning and time to try things out with the new version. This wouldn't actually be much different to what is done now, except for the naming. But by not officially blessing the latest release as current for a while, it might give less of an impression that stuff is being sprung on the community unawares. > OT1H I think there > will always be people or projects that won't try anything until the > gold release, Well, at least they've had a chance to try it. If they don't take that chance, they don't have much ground for complaint. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
Talin wrote: >> I think python should have a couple more of future imports. "from __future__ >> import new_classes" and "from __future__ import unicode_literals" would be >> really welcome, and would smooth the Py3k migration process > > Actually - can we make new-style classes the default, but allow a way to > switch to old-style classes if needed? Perhaps a command-line argument > to set the default back to old-style? so people complain about new releases breaking too much code, and your response to that is break even more code ? ___ 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] Community buildbots
Bob Ippolito wrote: > "from __future__ import new_classes" exists, but the syntax is > different: > > __metaclass__ = type Although it's not a very obvious spelling, particularly to the casual reader who may not be familiar with the intricacies of classes and metaclasses. I don't think it would hurt to have it available as a __future__ import as well. There's also the advantage that all of a module's future assumptions could then be documented uniformly in one place, i.e. in a __future__ import at the top. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 00:32, [EMAIL PROTECTED] wrote: > Same here. I believe there was some shortening of the 2.5 release cycle > two or three months ago. I don't recall why or by how much, but I think > the acceleration has resulted in a lot of the "can't we please squeeze > this one little change in?" that's been happening. Shortening a micro > release a bit seems reasonably easy to accommodate, but since minor > releases occur so infrequently, I think it would be better to stretch them > out if necessary. The squeezing of the releases isn't where the problem is, I think. It's that, once squeezed, more releases aren't being added to compensate. We really need to determine what time we need to go from beta1 to (gamma|rc)1, and then from (gamma|rc)1 to final. Plenty of interim releases in the beta phase is good. -Fred -- Fred L. Drake, Jr. ___ 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] Community buildbots (was Re: User's complaints)
Fred L. Drake, Jr. wrote: > It feels like the release cycle from alpha1 to final has gotten increasingly > rushed. python 2.2: ~5 months python 2.3: ~7 months python 2.4: ~5 months python 2.5: ~4 months I think the biggest problem is the time between "basically stable beta" and "final"; it was ~90 days in 2.3 and is now ~50 days, most of which is vacation time in my part of the world. we could extend the beta period by playing silly games with naming, but as long as the "big things" go in *before* the beta period starts, I think it's easier to simply extend the beta period by adding another month to it. I'd prefer something like 90 days. ___ 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] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 01:45, Fredrik Lundh wrote: > I'd prefer something like 90 days. +1 -Fred -- Fred L. Drake, Jr. ___ 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] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 06:05, Barry Warsaw wrote: > This really is an excellent point and makes me think that we may > want to consider elaborating on the Python release cycle to include > a gamma phase or a longer release candidate cycle. OT1H I think > there will always be people or projects that won't try anything > until the gold release, and that if we've broken anything in their > code we simply won't know it until after that, no matter how > diligent we are. OTOH, a more formal gamma phase would allow us to > say "absolutely no changes are allowed now unless it's to fix > backward compatibility". No more sneaking in new sys functions or > types module constants during the gamma phase. alpha 1: April 5, 2006 [completed] alpha 2: April 27, 2006 [completed] beta 1: June 20, 2006 [completed] beta 2: July 11, 2006 [completed] rc 1:August 1, 2006 [planned] final: August 8, 2006 [planned] Four months would seem to me to be quite long enough as a release cycle. Extending it means far more work for everyone - either we have special checkin rules for the trunk for a longer period of time (requiring extra monitoring by people like myself and Neal), or we branch earlier, requiring double commits to the trunk and the branch for bugfixes. I also strongly doubt that making a longer "release candidate" cycle would lead to any significant additional testing by end-users. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Community buildbots
Talin wrote: > Actually - can we make new-style classes the default, but allow a way to > switch to old-style classes if needed? That sounds dangerously like a "from __past__" kind of feature, and Guido has said that there will never be a __past__ module. Also, this is probably not something that should be a program-wide setting. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Fred> It feels like the release cycle from alpha1 to final has gotten > Fred> increasingly rushed. I think that's just because you are getting older and time goes by faster the less time you've got left. :-) It seems to be going quite quick, but I'm not so sure it's really different. > Same here. I believe there was some shortening of the 2.5 release cycle two > or three months ago. I don't recall why or by how much, but I think the > acceleration has resulted in a lot of the "can't we please squeeze this one > little change in?" that's been happening. Shortening a micro release a bit > seems reasonably easy to accommodate, but since minor releases occur so > infrequently, I think it would be better to stretch them out if necessary. Not exactly. The PEP was created Feb 7 (r42266) with a very relaxed schedule to allow enough time for ssize_t branch to solidify. Martin was ready sooner, so on Feb 26 (r42577) sped up the schedule to something more reasonable: -alpha 1: April 1, 2006 [planned] -alpha 2: April 29, 2006 [planned] -beta 1: June 24, 2006 [planned] -beta 2: July 15, 2006 [planned] -rc 1:August 5, 2006 [planned] -final: August 19, 2006 [planned] The current schedule is: +alpha 1: April 5, 2006 [completed] +alpha 2: April 27, 2006 [completed] +beta 1: June 20, 2006 [completed] +beta 2: July 11, 2006 [completed] +rc 1:August 1, 2006 [planned] +final: August 8, 2006 [planned] So beta1 was 4 days earlier than the date set at the end of Feb. The first beta was about 19 months after 2.4 was released if I'm counting correctly. In 2.4 beta1 to release was 1.5 months. For 2.5 it is about the same. The total 2.4 schedule (from a1 to release) was 4.5 months which included 3 alphas. For 2.5 we only had 2 alphas and the total schedule is just over 4 months. So 2.5 is just a little faster. But 2.5 has had a ton more testing than any previous released due to the buildbots, not to mention Coverity and now Klocwork. I definitely pushed the schedule, but I don't think it was really all that different from in the past. Given that several people here think we should lengthen the schedule in some way, I suspect we will do something. I'm not really against it, but I don't think it will provide much benefit either. A few more bugs will be fixed since we have more time. What I think might really make a difference if we could leverage the buildbots and copy the builds (especially WIndows) up to python.org and make them available for download. That might make it easier for people to try stuff out. n ___ 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] Community buildbots (was Re: User's complaints)
On 7/13/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote: > On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote: > > > > >There's been some recent discussion in the PSF wondering where it would > > >make sense to throw some money to remove grit in the wheels; do you think > > >this is a case where that would help? > > > > Most likely yes. It's not a huge undertaking, and there are a lot of > > people out > > there in the community with the knowledge of Buildbot to make this happen. > > I'm at least willing to set up the buildbots for projects I care about > (Twisted, pydoctor, whatever), and perhaps help out with the setting > up the buildmaster. It would be really great to have someone setup buildbots for other important/large python projects to test python svn HEAD with. I can't even stay on top of the python buildbots, so I'm not volunteering for more work. I will greatly appreciate and thank whoever takes this on though. :-) The harder problem is keeping it running. Setting it up, in some ways is a lot easier. It's at least well defined. Maintaining it for several months is a different story. n ___ 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] Community buildbots (was Re: User's complaints)
Neal Norwitz wrote: > Given that several people here think we should lengthen the schedule > in some way, I suspect we will do something. I'm not really against > it, but I don't think it will provide much benefit either. A few more > bugs will be fixed since we have more time. you're still missing the point of this thread: it isn't bugs in the core Python distribution that's the problem, it's compatibility with third- party modules and applications. I'm quite sure that we could ship the current beta2 as 2.5 final and have a Python release that, in itself, is more stable than all the ones before it, but since 2.5 introduces lots of new stuff, that stability doesn't necessarily translate to a better experience for people who wants to use their existing applications and libraries. a longer beta period gives *external* developers more time to catch up, and results in less work for the end users. ___ 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] Community buildbots (was Re: User's complaints)
On 7/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > > Given that several people here think we should lengthen the schedule > > in some way, I suspect we will do something. I'm not really against > > it, but I don't think it will provide much benefit either. A few more > > bugs will be fixed since we have more time. > > you're still missing the point of this thread: it isn't bugs in the core > Python distribution that's the problem, it's compatibility with third- > party modules and applications. ... > a longer beta period gives *external* developers more time to catch up, > and results in less work for the end users. This is the part I don't get. For the external developers, if they care about compatibility, why aren't they testing periodically, regardless of alpha/beta releases? How often is the python build broken or otherwise unusable? On Unix there's no more or less work to grab a tarball whether it's a nightly or a release. For Windows it's definitely easier to wait for a release. If there was an installable windows version made by the buildbots, would that mean there would be more testing? Is part of your point that these developers only care about something called "release" and they won't start testing before then? If that's the case why don't we start making (semi-)automated alpha releases every month? That will give people lots more time. Somehow I don't think it will make a difference. People mostly work on schedules or should I say avoid schedules. Give them 5 months and they will still wait to the last minute. Remember I also tried to push for more features to go in early? That would have given more time for external testing. Still features are coming in. Python developers weren't happy about having to get things in earlier. I don't see a practical way to implement what you propose (see Anthony's comments). n ___ 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
