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 information.
> >>> import xml
> >>> xml.dom
>
>
> Python 2.4.2 (#
On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> Some comments on the code:
>
> > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>
> Can we get rid of these absolute paths? Something like this should suffice:
>
> >>> from ctypes import *
> >>> buf = create_string_buffer(4096)
> >>> windl
On Sun, 11 Jun 2006, Phillip J. Eby wrote:
> At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
> >I've added code to make uuid1() use uuid_generate_time() if available
> >and uuid4() use uuid_generate_random() if available. These functions
> >are provided on Mac OS X (in libc) and on Linux (in libuu
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>>> for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>>
>> Can we get rid of these absolute paths? Something like this should
>> suffice:
>>
> from ctypes import *
> buf = create_string_buffer(4096)
> windll.kernel32.GetSystemDirecto
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the
H.Yamamoto wrote:
> - Original Message -
> From: "Walter Dörwald" <[EMAIL PROTECTED]>
> To: "H.Yamamoto" <[EMAIL PROTECTED]>
> Cc: "python-dev"
> Sent: Friday, June 09, 2006 7:56 PM
> Subject: Re: [Python-Dev] beta1 coming real soon
>
>> The best way to throughly test the patch is of co
On 6/12/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> > Some comments on the code:
> >
> > > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
> >
> > Can we get rid of these absolute paths? Something like this should suffice:
> >
> > >>> from
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.
Skip
___
Python-Dev m
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, to be looked up thereafter.
An
Martin v. Löwis wrote:
> Sam Ruby wrote:
>> If we can agree on the behavior, I would be glad to write up a patch.
>>
>> It seems to me that the simplest way to proceed would be for the code
>> that attempts to resolve character references (both named and numeric)
>> in attributes to be isolated in
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 Python 2.5 compiles
>> the following code incorrectly:
>
> No
I notice that file()
throws an IOError when it detects an invalid mode string. Wouldn't a
ValueError be more appropriate?
Kristján
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
Alex Martelli wrote:
>...claims:
>
>Note that for even rather small len(x), the total number of
>permutations of x is larger than the period of most random number
>generators; this implies that "most" permutations of a long
>sequence can never be generated.
>
>Now -- why would the behavior of "mos
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 trying it
and catching IOError,
Sam Ruby wrote:
> I don't see why expanding to multiple characters is a problem.
That isn't a problem. Expanding to unparsed entities is. So the
current call to handle_entityref must remain.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
At 12:44 AM 6/12/2006 +0200, Fredrik Lundh wrote:
>the compiler can of course figure that out also for if/elif/else state-
>ments, by inspecting the AST. the only advantage for switch/case is
>user syntax...
Not quite true - you'd have to restrict the switch expression in some way,
so you don't
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 find that it doesn't correspond to any particular point in
the
At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
>Thomas Heller wrote:
> > I don't know if this is the uuidgen you're talking about, but
> > on linux there is libuuid:
>
>Thanks!
>
>Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py .
>
>Phillip J. Eby wrote:
> > By the way, I
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
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 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
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
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
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
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, 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
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
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
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
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.
>
>
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
-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, 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
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 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.
___
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 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
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,
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
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
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, 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
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
[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
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
> 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
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
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
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
[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:
> 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
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
>
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, 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
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
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
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
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
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 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
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 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, 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
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
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
-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
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
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
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
>
[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
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
[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
>>
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
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-
[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
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
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
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
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
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, 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
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
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 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 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 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
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
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
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
[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
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
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
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
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: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
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
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
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
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
1 - 100 of 119 matches
Mail list logo
