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
>
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 mis
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 s
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
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 th
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 tha
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
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
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
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 woul
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 a
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 k
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-st
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
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
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-De
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
sy
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
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
gly
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
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
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
> "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.
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 thi
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
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
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 undert
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 futur
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 glyp
[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 __fu
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
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 managemen
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
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 dlmod
-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
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
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
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 rath
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:
>
>
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
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 th
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 excellen
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 usef
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(...
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
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 "excoriate
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 bo
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 i
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
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 m
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
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 block
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 "wi
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
-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 see
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 c
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__":
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 th
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 stup
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 need
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).
>
>
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 t
>> 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 mig
"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
Python-Dev@python.org
http://mail.python.org/mailman/
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 standar
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
[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 differ
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
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
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 l
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
>> n
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
Python-Dev@python.org
http
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-imp
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. 'impor
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
Pyt
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 o
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
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 nuisan
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 p
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.
>
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
81 matches
Mail list logo
