Ok, here's the summary for the second half of April. My brain is numb
from the setuptools ane PEP 343 discussions, so please have a look
over it and see what I messed up. ;-)
As always, if you have any corrections or comments, please let me know.
=
Announcements
=
-
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:
> >IMO, the better way is exactly this you depicted: move the official
> >development
> >tree into this Externals/ dir *within* Python's repository. Off that, you can
> >have your own branch fo
> this is mildy insulting, to the people that spent time trying to find
> the best compromises between various issues and keep jython alive.
Sorry, didn't mean to disparage that work.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
On Mon, Jun 12, 2006 at 11:33:49PM +0200, Michael Walter wrote:
> Maybe "switch" became a keyword with the patch..
>
> Regards,
> Michael
>
That's correct.
> On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> > Could you upload your patch to SourceForge ? Then I could add
> > it to the
Phillip J. Eby wrote:
[...]
> So, to summarize, it's all actually Tim's fault, but only in a parallel
> universe where nobody believes in unit testing. ;-)
>
I'm sorry to contradict you, but every issue of significance is already
known to be Barry's fault.
probably-until-the-end-of-time-ly y'r
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:>IMO, the better way is exactly this you depicted: move the official>development>tree into this Externals/ dir *within* Python's repository. Off that, you can
>have your own branch for experimenta
At 01:49 AM 6/13/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > This should definitely be explained to authors who are donating
> > libraries to the stdlib, because from my perspective it seemed to me
> > that I was graciously volunteering to be responsible for *all* the work
> > rel
[EMAIL PROTECTED] wrote:
> Greg> A way out of this would be to define the semantics so that the
> Greg> expression values are allowed to be cached, and the order of
> Greg> evaluation and testing is undefined. So the first time through,
> Greg> the values could all be put in a dict,
[EMAIL PROTECTED] wrote:
> Greg> Multiple values could be written
>
> Greg>case 'a':
> Greg>case 'b':
> Greg>case 'c':
> Greg> ...
>
> That would be an exception to the rule that a line ending in a colon
> introduces an indented block.
Yes, but I don't see th
[Raymond Hettinger]
> I think the note is still useful, but the "rather small" wording
> should be replaced by something most precise (such as the
> value of n=len(x) where n! > 2**19997).
Note that I already removed it, and I'm not putting it back. The
period of W-H was "so short" you could get
It's sounding like a rewording of PEP 360 would help this whole external code issue. If it was changed to say that non-API changes could be directly checked in would that help?That would mean the PEP would list the contact person and what external version corresponds to what Python release. Basic
At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:
>IMO, the better way is exactly this you depicted: move the official
>development
>tree into this Externals/ dir *within* Python's repository. Off that, you can
>have your own branch for experimental work, from which extract your own
>releases, and
Yes, this is because of the (unfortunate) availability of the dup()
operation. Originally, dup() was only available on Unix, where it's
implemented in the kernel at the file descriptor level: when several
file descriptors all share the same underlying socket, the socket
isn't really closed until th
Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Control isn't the issue; it's ensuring that fixes don't get lost or
> reverted from either the external version or the stdlib version.
> Control
> is merely a means to that end. If we can accomplish that via some
> other
> means (e.g. an Externals/ subt
At 01:36 AM 6/13/2006 +0200, Martin v. Löwis wrote:
> From that, I can only conclude that you requested that people should
>not make changes again without contacting you or the Web-SIG.
Indeed I was -- back when I was under the mistaken impression that PEP 360
actually meant what it appeared to s
Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> It would be an important move towards world peace, if it didn't
>> inspire whole new SCM-holy-wars :-) I have a fair bit of experience with
>> different
>> SCM (VC, source control tool, however you want to call them) so I'll
>> take
>> this opportunity
On Mon, 12 Jun 2006, Giovanni Bajo wrote:
> GetSystemDirectory() is the official way to find the system directory.
You're right. I've added a call to GetSystemDirectory, with a fallback
to the usual locations if it doesn't work.
> Another thing that you might do is to drop those absolute system
Terry Jones wrote:
> The code below uses a RNG with period 5, is deterministic, and has one
> initial state. It produces 20 different outcomes.
You misunderstand what's meant by "outcome" in this
context. The outcome of your algorithm is the whole
*sequence* of numbers it produces, not each indiv
[Phillip J. Eby]
>> Actually, I started out with "please" -- twice, after having previously
>> asked please in advance. I've also seen lots of messages on Python-Dev
>> where Tim Peters wrote about having wasted time due to other folks not
>> following established procedures, and I tried to emulat
Phillip J. Eby wrote:
> This should definitely be explained to authors who are donating
> libraries to the stdlib, because from my perspective it seemed to me
> that I was graciously volunteering to be responsible for *all* the work
> related to wsgiref.
It's not only about python-wide changes. It
In implementing the IronPython _socket module, I've discovered some
puzzling behavior in the standard Python socket wrapper module:
socket._socketobject.close() doesn't actually close sockets; rather, it
just sets _sock to an instance of _closedsocket and lets the GC clean up
the real socket. (See
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Armin Rigo wrote:
> > Hi,
> >
> > On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
> >> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
> >> doesn't get forgotten before 2.5 goes out ;) It seems Pytho
Phillip J. Eby wrote:
> At 12:28 AM 6/13/2006 +0200, Martin v. Löwis wrote:
>> If you remember that this is the procedure: sure. However, if the
>> maintainer of a package thinks (and says) "somebody edited my code,
>> this should not happen again", then I really think the code is better
>> not par
At 12:09 AM 6/13/2006 +0100, Steve Holden wrote:
>Phillip J. Eby wrote:
> > Anyway, will anyone who was offended by the original message please
> pretend
> > that it was delightfully witty and written by Tim instead? Thanks. ;)
> >
>I wonder what the hell's up with Tim. He's been really crabby l
At 12:56 AM 6/13/2006 +0200, Martin v. Löwis wrote:
>Fredrik Lundh wrote:
> >> I just want changes made by the Python core developers to be reflected in
> >> the external releases.
> >
> > and presumably, the reason for that isn't that you care about your ego,
> > but that you care about your users
At 12:28 AM 6/13/2006 +0200, Martin v. Löwis wrote:
>If you remember that this is the procedure: sure. However, if the
>maintainer of a package thinks (and says) "somebody edited my code,
>this should not happen again", then I really think the code is better
>not part of the Python distribution.
T
Phillip J. Eby wrote:
> [posting back to python-dev in case others also perceived my original
> message as impolite]
>
> At 01:25 PM 6/12/2006 -0700, Guido van Rossum wrote:
>
>>Oh, and the tone of your email was *not* polite. Messages starting
>>with "I wasted an hour of my time" are not polite
Guido van Rossum wrote:
> PyXML appears pretty stable (in terms of release frequency -- I have
> no opinion on the code quality :-). Perhaps it could just be
> incorporated into the Python svn tree, if the various owners are
> willing to sign a contributor statement?
That is, in itself, a medium-s
[EMAIL PROTECTED] wrote:
>
>
> Greg> Before accepting this, we could do with some debate about the
> Greg> syntax. It's not a priori clear that C-style switch/case is the
> Greg> best thing to adopt.
>
> Oh sure. That debate should probably leverage PEP 275.
Along the lines of PEP
Fredrik Lundh wrote:
>> I just want changes made by the Python core developers to be reflected in
>> the external releases.
>
> and presumably, the reason for that isn't that you care about your ego,
> but that you care about your users.
For that, yes. However, the reason to desire that no chan
Phillip J. Eby wrote:
> Actually it's both irrelevant and insulting.
>
> I just want changes made by the Python core developers to be reflected in
> the external releases. I'd be more than happy to move the external release
> to the Python SVN server if that would make it happen.
>
I think th
Brett Cannon wrote:
> Well, I don't know if that is necessarily the case. PEP 360 doesn't
> have a single project saying that minor fixes can just go right in. If
> we want to just change the wording such that all code in the tree can be
> touched for bug fixes and compatibility issues without cl
On 6/13/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Mon, Jun 12, 2006 at 11:31:14PM +0200, Thomas Wouters wrote:> First of all, changing SCM means changing how everyone works. Distributed branches is not the only requirement. Oh, I know, no worries about that.
There are also:-- subtree auth
Fredrik Lundh wrote:
>> But I don't think this is trying to say they don't care. People just want
>> to lower the overhead of maintaining the distro.
>
> well, wouldn't the best way to do that be to leave all non-trivial
> maintenance of a
> given component to an existing external community?
If
On Mon, Jun 12, 2006 at 11:31:14PM +0200, Thomas Wouters wrote:
> First of all, changing SCM means changing how everyone works.
Distributed branches is not the only requirement. There are also:
-- subtree authorization (different access rights in different parts of the
tree); in distributed
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error
On 6/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> [*] Short? This whole mail was short! I can talk for hours about the benefit
> of proper branches and what kind of stuff is easier, better and more
> efficient with them. I can draw huge ASCII diagrams explaining the
> fundamental difference b
On 6/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]
> wrote:
Perhaps issues like these should motivate us to consider a differentsource control tool. There's a new crop of tools out that could solvethis by having multiple repositories that can be sy
Maybe "switch" became a keyword with the patch..
Regards,
Michael
On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Hi all,
> >
> > As the subject of this e-mail says, the attached patch adds a "switch"
> > statement to the Python language.
> >
> > However, I've been re
On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Perhaps issues like these should motivate us to consider a differentsource control tool. There's a new crop of tools out that could solvethis by having multiple repositories that can be sync'ed with eachother. This sounds like an important mov
Tim Peters wrote:
> Which OS and compiler were in use? A possible cause is that the
> platform didn't supply #defines for SIZEOF_DOUBLE and/or SIZEOF_FLOAT
> when Python was compiled. This was, e.g., true on Windows before rev
> 46065.
and looking again, I was indeed running 2.5 alpha 2 (revisi
Phillip J. Eby wrote:
> I just want changes made by the Python core developers to be reflected in
> the external releases.
and presumably, the reason for that isn't that you care about your ego,
but that you care about your users.
___
Python-Dev ma
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Phillip J. Eby wrote:> I'd still rather have a Packages/ directory, but beggars can't be > choosers.there's plenty of time to work on that for 2.6...I have started a thread on python-3000 to try to get a PEP pulled together to solidify what we wa
[Fredrik Lundh]
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error is somewhat confusing: since
Phillip J. Eby wrote:
> I'd still rather have a Packages/ directory, but beggars can't be
> choosers.
there's plenty of time to work on that for 2.6...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
At 03:42 PM 6/12/2006 -0400, Edward C. Jones wrote:
>Guido van Rossum wrote:
> > developers contributing code without wanting
> > to give up control are the problem.
>
>That hits the nail on the head.
Actually it's both irrelevant and insulting.
I just want changes made by the Python core devel
[Tim]
>> In addition, not shown above is that I changed test_wsgiref.py to stop
>> a test failure under -O. Given that we're close to the next Python
>> release, and test_wsgiref was the only -O test failure, I wasn't going
>> to let that stand. I did wait ~30 hours between emailing about the
>>
A01:01 PM 6/12/2006 -0700, Guido van Rossum wrote:
>I think I pretty much did already -- going forward, I'd like to see
>that contributing something to the stdlib means that from then on
>maintenance is done using the same policies and guidelines as the rest
>of the stdlib (which are pretty conserv
[posting back to python-dev in case others also perceived my original
message as impolite]
At 01:25 PM 6/12/2006 -0700, Guido van Rossum wrote:
>Oh, and the tone of your email was *not* polite. Messages starting
>with "I wasted an hour of my time" are not polite pretty much by
>definition.
Actua
Guido van Rossum wrote:
> On 6/12/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I will be happy to say "ctypes is part of Python" (although I *fear* it
>> is not one of the packages enthusiastically supported by Guido ;-).
>
> I don't plan to use it myself, but I'm very happy that it's in the
>
On 6/12/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> I will be happy to say "ctypes is part of Python" (although I *fear* it
> is not one of the packages enthusiastically supported by Guido ;-).
I don't plan to use it myself, but I'm very happy that it's in the
stdlib since so many people like i
Paul Moore wrote:
> This is purely speculation (and fairly negative speculation at that!)
> but I'd advocate caution for a while yet. Maybe ActiveState or
> Enthought could provide some input on how/if sumo bundles can address
> the need to upgrade "parts" of the distribution?
We at Enthought are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Jun 2006 15:12:20 -0400
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> Now, Barry's approach to the email package makes good sense to me,
> and I'd use it, except that SVN externals can't sync individual
> files. I'd have to create Lib/wsgi
I just ran the PIL test suite using the current Python trunk, and the
tests for a user-contributed plugin raised an interesting exception:
ValueError: can't unpack IEEE 754 special value on non-IEEE platform
fixing this is easy, but the error is somewhat confusing: since when is
a modern Intel
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>>> 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
>>> to get rid of it, *now* would be the time.
>>
>> I'm all for it.
>>
>> While I am an enthusiastic supporter of several of those additions, I
>> am *not* in favor of t
On 6/12/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> IMHO we should
> require all modules with version constraints or external master source
> to have comments indicating this *in the code*, at the top of every
> source file, so that someone writing a patch or bugfix knows what the
> requirements
On 6/12/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > developers contributing code without wanting
> > to give up control are the problem.
>
> That hits the nail on the head. If something is added to the standard
> library, it becomes part of Python and must be cont
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Maybe we should get serious about slimming down the core distribution
> > and having a separate group of people maintain sumo bundles containing
> > Python and lots of other stuff.
>
> there are already lots of peo
On Mon, Jun 12, 2006 at 03:12:20PM -0400, Phillip J. Eby wrote:
> encountered this myself. I *have* seen some developers make spurious
> "cleanups" to working code that breaks compatibility with older Python
> versions, though, just not in wsgiref.
Note that the standard library policy has alwa
At 03:29 PM 6/12/2006 -0400, Tim Peters wrote:
>That's all ordinary everyday maintenance, and, e.g., there is no
>mechanism to exempt anything in a checkout tree from reindent.py or
>PyChecker complaints.
>
>In addition, not shown above is that I changed test_wsgiref.py to stop
>a test failure unde
On Mon, Jun 12, 2006 at 11:25:21AM -0700, Guido van Rossum wrote:
> Have any instances of that actually happened? That would be a problem
> with *any* code in the Python library, not just external
> contributions, so I'm not sure why external contribions should be
> treated any differently here.
T
writes:
> what [Python] specification?
Good meta-point.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Guido van Rossum wrote:
> developers contributing code without wanting
> to give up control are the problem.
That hits the nail on the head. If something is added to the standard
library, it becomes part of Python and must be controlled by whoever
controls Python. Otherwise there will be chaos
No, because ValueError is the better exception for an invalid mode string.
On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
> >> > Yup, although it's a change in behavior that would ne
On 6/12/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > Here's how I interpret PEP 237. Some changes to hex() and oct() are
> > warned about in B1and to be implemented in B2. But I'm pretty sure
> > that was about the treatment of negative numbers, not about the
> > trailing 'L'. I believe
Guido van Rossum wrote:
> On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Yup, although it's a change in behavior that would need to be studied
>> > carefully for backwards incompatibilities. Usually it's given as a
>> > constant, so there won't be any problems;
On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Yup, although it's a change in behavior that would need to be studied
> > carefully for backwards incompatibilities. Usually it's given as a
> > constant, so there won't be any problems; but there might be code that
>
Bill Janssen wrote:
> If it's Python, it has to comply with the Python specification,
> regardless of what Java does.
what specification ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
[Brett]
>> But I don't think this is trying to say they don't care. People just want
>> to lower the overhead of maintaining the distro.
[Fredrik]
> well, wouldn't the best way to do that be to leave all non-trivial
> maintenance of a
> given component to an existing external community?
>
> (aft
Bill Janssen wrote:
>>the difference in Jython is deliberate. I think the reason was to mimic
>>more the Java style for this, in java fully qualified names always work.
>>In jython importing the top level packages is enough to get a similar
>>effect.
>>
>>This is unlikely to change for backward
At 11:23 AM 6/12/2006 -0700, Guido van Rossum wrote:
>developers contributing code without wanting
>to give up control are the problem.
Control isn't the issue; it's ensuring that fixes don't get lost or
reverted from either the external version or the stdlib version. Control
is merely a means
Guido van Rossum wrote:
> Yup, although it's a change in behavior that would need to be studied
> carefully for backwards incompatibilities. Usually it's given as a
> constant, so there won't be any problems; but there might be code that
> receives a mode string and attempts to test its validity by
> the difference in Jython is deliberate. I think the reason was to mimic
> more the Java style for this, in java fully qualified names always work.
> In jython importing the top level packages is enough to get a similar
> effect.
>
> This is unlikely to change for backward compatibility reason
On Mon, Jun 12, 2006 at 10:42:44AM -0700, Guido van Rossum wrote:
> standard library code is just more of a maintenance burden. Maybe we
> should get serious about slimming down the core distribution and
> having a separate group of people maintain sumo bundles containing
> Python and lots of other
[Guido]
> Here's how I interpret PEP 237. Some changes to hex() and oct() are
> warned about in B1and to be implemented in B2. But I'm pretty sure
> that was about the treatment of negative numbers, not about the
> trailing 'L'. I believe the PEP authors overlooked the trailing 'L'
> for hex() and
At 10:42 AM 6/12/2006 -0700, Guido van Rossum wrote:
>Sure, but this doesn't require the draconian "I-and-I-only own the
>code" approach that you have.
If there were only one version and directory tree to maintain to do both
the Python trunk and the external version, I wouldn't mind other people
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> But I don't think this is trying to say they don't care. People just want> to lower the overhead of maintaining the distro.well, wouldn't the best way to do that be to leave all non-trivial maintenance of a
given component t
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I mean, we're not really talking about ordinary leak-elimination or
> portability-fixing
> or security-hole-plugging maintenance; it's the
> let's-extend-the-api-in-incompatible-
> ways and fork-because-we-can stuff that I'm worried about.
H
On 6/12/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >>> I personally think that, going forward, external maintainers should
> >>> not be granted privileges such as are being granted by PEP 360, and
> >>> an inclusion of a package in the Python tree should be considere
Guido van Rossum wrote:
>>> I personally think that, going forward, external maintainers should
>>> not be granted privileges such as are being granted by PEP 360, and
>>> an inclusion of a package in the Python tree should be considered a
>>> "fork" for all practical purposes. If an external deve
Brett Cannon wrote:
> But I don't think this is trying to say they don't care. People just want
> to lower the overhead of maintaining the distro.
well, wouldn't the best way to do that be to leave all non-trivial maintenance
of a
given component to an existing external community?
(after all,
On 12 Jun 2006, at 02:19, Terry Jones wrote:
>> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
>
> Greg> Terry Jones wrote:
>>> Suppose you have a RNG with a cycle length of 5. There's nothing
>>> to stop an
>>> algorithm from taking multiple already returned values and
>>> combining the
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:> Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the> status of each of these has been clarified.>> Each maintainer should indicate whether he is happy with a "this is
> part of Python" approach. If so,
On Monday 12 June 2006 13:42, Guido van Rossum wrote:
> Maybe we
> should get serious about slimming down the core distribution and
> having a separate group of people maintain sumo bundles containing
> Python and lots of other stuff.
+1
-Fred
--
Fred L. Drake, Jr.
___
Guido van Rossum wrote:
> Maybe we should get serious about slimming down the core distribution
> and having a separate group of people maintain sumo bundles containing
> Python and lots of other stuff.
there are already lots of people doing that (most Linux distributions add
stuff, directly
or
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> is this "we don't give a fuck about 3rd party developers and users" attitude
> really representative for the python-dev community and the PSF ?
If you want the PSF to listen to you should watch your language. I'm
out of here, back to focusing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Jun 2006 13:08:52 -0400
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> While I won't claim to speak for the other authors, I would guess
> that they have the same reason for wanting that status as I do: to be
> able to maintain an external r
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote:
> >On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
> >> >IOW I think PEP 360 is an unfortunate historic accident, and we would
Thomas Lee wrote:
> Hi all,
>
> As the subject of this e-mail says, the attached patch adds a "switch"
> statement to the Python language.
>
> However, I've been reading through PEP 275 and it seems that the PEP
> calls for a new opcode - SWITCH - to be added to support the new
> construct.
>
>
At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote:
>On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
>> >IOW I think PEP 360 is an unfortunate historic accident, and we would
>> >be better off without it. I propose that we don't add to i
Guido van Rossum wrote:
>> 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
>> to get rid of it, *now* would be the time.
>
> I'm all for it.
>
> While I am an enthusiastic supporter of several of those additions, I
> am *not* in favor of the special status granted to sof
Here's how I interpret PEP 237. Some changes to hex() and oct() are
warned about in B1and to be implemented in B2. But I'm pretty sure
that was about the treatment of negative numbers, not about the
trailing 'L'. I believe the PEP authors overlooked the trailing 'L'
for hex() and oct(). I think the
On 6/12/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> Fabio Zadrozny wrote:
> > Python and Jython import semantics differ on how sub-packages should be
> > accessed after importing some module:
> >
> > Jython 2.1 on java1.5.0 (JIT: null)
> > Type "copyright", "credits" or "license" for more info
PyXML appears pretty stable (in terms of release frequency -- I have
no opinion on the code quality :-). Perhaps it could just be
incorporated into the Python svn tree, if the various owners are
willing to sign a contributor statement?
--Guido
On 6/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wro
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
> >IOW I think PEP 360 is an unfortunate historic accident, and we would
> >be better off without it. I propose that we don't add to it going
> >forward, and that we try to get rid of it as
Walter Dörwald wrote:
>>> The best way to throughly test the patch is of course to check it in. ;)
>> Is it too risky? ;)
>
> At least I'd like to get a second review of the patch.
I've reviewed it, and am likely to check it in. I notice that the
patch still has problems. In particular, it is lim
Ka-Ping Yee wrote:
> I'd like to, but i don't want to use a method for finding the system
> directory that depends on ctypes. Is there a more general way?
I think
os.path.join(os.environ["SystemRoot"], "system32")
should be fairly reliable. If people are worried that the directory
might not be
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
>IOW I think PEP 360 is an unfortunate historic accident, and we would
>be better off without it. I propose that we don't add to it going
>forward, and that we try to get rid of it as we can.
4 of the 6 modules in PEP 360 were added to Python in
On 6/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> As requested in PEP 360, please inform me of any issues you find so they
> can be corrected in the standalone package and merged back to the trunk.
>
> I just wasted time cutting an 0.1.1 release of the standalone wsgiref
> package only to fin
At 03:22 PM 6/10/2006 -0400, Tim Peters wrote:
>This may be because compare_generic_iter() uses `assert` statements,
>and those vanish under -O. If so, a test shouldn't normally use
>`assert`. On rare occasions it's appropriate, like test_struct's:
>
> if x < 0:
> expe
1 - 100 of 119 matches
Mail list logo
