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 a single method. Subclasses that
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)
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 libuuid).
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.GetSystemDirectoryA(buf, 4096)
17
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
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
H.Yamamoto wrote:
- Original Message -
From: Walter Dörwald [EMAIL PROTECTED]
To: H.Yamamoto [EMAIL PROTECTED]
Cc: python-dev python-dev@python.org
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
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 ctypes import *
Greg Multiple values could be written
Gregcase 'a':
Gregcase 'b':
Gregcase 'c':
Greg ...
That would be an exception to the rule that a line ending in a colon
introduces an indented block.
Skip
___
Python-Dev
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.
And
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 a single
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, no, it's
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:
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 most random
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
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
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'd love to
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:
expected
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 find that
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 limited
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] wrote:
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 information.
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
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 software
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 it going
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.
I got a bit
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
be better
-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 release
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 on
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. fdrake at acm.org
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, the
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 them
in some
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 developer is not
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 considered a
fork for
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.
Have
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 to an
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 reasons, at
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
[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?
(after all,
Bill Janssen wrote:
If it's Python, it has to comply with the Python specification,
regardless of what Java does.
what specification ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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; but there
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 the PEP
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 need to be
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.
/F 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:
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.
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 under -O.
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 always
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 people doing
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 controlled by
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 are.
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 the special
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
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 it.
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
stdlib
[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.
Actually,
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
[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
problem
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 developers
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...
/F
___
Python-Dev mailing list
Python-Dev@python.org
[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 when
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 want
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.
/F
___
Python-Dev
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 (revision
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 move
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 reading through PEP
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
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
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 is
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 you
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
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
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 the
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 changes
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
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 pretty
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.
The
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.
For that,
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 lately
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 part of the
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 Python 2.5 compiles
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]
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 emulate his
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
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
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 to toss up
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
1 - 100 of 114 matches
Mail list logo
