On Tuesday 06 March 2007 5:42 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
1. Don't suggest to people that, in order to get their patch reviewed,
they should review other patches. The level of knowledge required to put
together a patch is much less than that required to know if a patch
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
I'm not sure what your point is. My point is that, if you want to
encourage people to become core developers, they have to have a method of
graduating through the ranks - learning (and being taught) as they go.
On 3/5/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't know too many good use cases for
locals() apart from learning about the implementation I think this
might be okay.
Since I'm watching this list for any discussion on the traceback
threads, I figured I would point out the most common
On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
Any ideas for fixing this problem?
A better patch-tracker, better procedures for reviewing patches
surounding this new tracker, one or more proper dvcs's for people to
work off of. I'm not sure about
On 3/6/07, Phil Thompson [EMAIL PROTECTED] wrote:
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
I'm not sure what your point is. My point is that, if you want to
encourage people to become core developers, they have to have a method of
graduating
On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they
Stephen J. Turnbull schrieb:
An informal version of this process is how XEmacs identifies its
Reviewers (the title we give to those privileged to authorize commits
to all parts of XEmacs). People who care enough to make technical
comments on *others'* patches are rare, and we grab the
On 3/6/07, Neil Schemenauer [EMAIL PROTECTED] wrote:
Using git-svn to track a SVN repository seems to work well.
I'm not interested in setting up GIT myself, mostly because it doesn't solve
any issues that other dvcs' don't solve, the on-disk repository is mighty
big and it doesn't work very
Phil Thompson schrieb:
2. Publically identify the core developers and their areas of expertise
and responsibility (ie. which parts of the source tree they own).
I doubt this will help. Much of the code isn't owned by anybody
specifically. Those parts that are owned typically find their
Phil Thompson schrieb:
And please be assured that no such obstacle is in the submitters way.
Most patches are accepted without the submitter actually reviewing any
other patches.
I'm glad to hear it - but I'm talking about the perception, not the fact.
When
occasionally submitters ask if
Phil Thompson schrieb:
Of course it's not unreasonable. I would expect to be told that a patch
must have tests and docs before it will be finally accepted. However,
before I add those things to the patch I would like some timely feedback
from those with more experience that my patch is going
Phil Thompson schrieb:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment people just seem be
saying that's the way it is because that's
Phil Thompson writes:
MvL wrote:
I doubt this will help. Much of the code isn't owned by anybody
specifically. Those parts that are owned typically find their patches
reviewed and committed quickly (e.g. the tar file module, maintained by
Lars Gustäbel).
Doesn't your last
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
Eric V. Smith schrieb:
I'm working on PEP 3101, Advanced String Formatting. About the only
built-in numeric formatting I have left to do is for converting a
PyLongOjbect to binary.
I need to know how to access the
Martin v. Löwis writes:
Stephen J. Turnbull schrieb:
Second, where the stdlib module is closely bound to the core, the
maintainer ends up being the group of core developers. It can't be
any other way, it seems to me.
It might be that individuals get designated maintainers: Guido
On 06/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Scott Dial schrieb:
While I understand that this tit-for-tat mechanism is meant to ensure
participation, I believe in reality it doesn't, as the 400-some
outstanding patches you referenced elswhere indicate. I can personally
attest to
Paul Moore schrieb:
Scott Dial schrieb:
While I understand that this tit-for-tat mechanism is meant to ensure
participation, I believe in reality it doesn't, as the 400-some
outstanding patches you referenced elswhere indicate. I can personally
attest to having a patch that is over a year old
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
#1462106 contains a patch for that, changing the behavior
so that there will always be a root file name (and no
extension if the file is just a dotfile).
Should this be changed?
On 3/6/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
#1462106 contains a patch for that, changing the behavior
so that there will always be a root file name (and no
extension if
On Tue, Mar 06, 2007 at 01:36:03PM +0100, Martin v. L?wis wrote:
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
#1462106 contains a patch for that, changing the behavior
so that there will always be a root file name (and no
On 3/5/07, Dino Viehland [EMAIL PROTECTED] wrote:
Thanks Guido. It might take some time (and someone may very well beat me to
it if they care a lot) but I'll see if we can get the PEP started.
Dino,
One of the questions I was puzzling over was what locals() should
return in a class scope.
Martin v. Löwis schrieb:
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
#1462106 contains a patch for that, changing the behavior
so that there will always be a root file name (and no
extension if the file is just a
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they have good use for them.
Ask the
On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote:
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people
Am Dienstag, 06. März 2007 13:36 schrieb Martin v. Löwis:
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
#1462106 contains a patch for that, changing the behavior
so that there will always be a root file name (and no
Martin v. Löwis wrote:
Eric V. Smith schrieb:
I'm working on PEP 3101, Advanced String Formatting. About the only
built-in numeric formatting I have left to do is for converting a
PyLongOjbect to binary.
I need to know how to access the bits in a PyLong.
I think it would be a major
On Tue, Mar 06, 2007 at 02:44:52PM +0100, Hans Meine wrote:
a leading dot does not start an
extension, but marks a file as hidden. The latter is on UNIX, and while
On Unix - I mean in the OS itself - there are no such things as roots,
extensions and hidden files. All these are only
Oleg Broytmann wrote:
[snip..]
this is different on Windows, I cannot imagine that anyone would
a) have dotfiles under that OS
It is very common for cross platform programs to create configuration
files which are dotfiles, whichever OS they are running on.
Michael Foord
Hi list,
A month and a half ago, I submitted patch 1644818 to the CPython Patch
Tracker:
https://sourceforge.net/tracker/?func=detailatid=305470aid=1644818group_id=5470
On several occassions I have been advised to mention the patch in this list,
so here it is:
The problem: Importing built-in
Georg Brandl wrote:
As far as I recall, there has been nearly no one who asked for commit rights
recently, so why complain that the entry barrier is too great? Surely you
cannot expect python-dev to got out and say would you like to have commit
privileges?...
I think the number one suggestion
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment people just seem be
On Tue, Mar 06, 2007 at 07:59:53AM +0100, Ronald Oussoren wrote:
development easier for them. They can already do this using SVK,
which is a distributed version control system as well but uses SVN
repositories to store its data.
I'm happy to write up a wiki page describing how to use SVK
Oleg Broytmann schrieb:
Should this be changed? Opinions?
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension. However, for .pythonrc, it would conclude
that .pythonrc is the
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension.
Ah, sorry. I messed it with .split().
Oleg.
--
Jeremy Hylton schrieb:
You can ask whether we should have a plan for increasing the number of
developers, actively seeking out new developers, and mentoring people
who express interest. Would the code be better if we had more good
developers working on it? Would we get more bugs fixed and
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension.
Ah, sorry. I messed it with
Neil Schemenauer schrieb:
the on-disk repository is mighty big and it doesn't work very well
on non-Linux systems (at least, not last I looked.)
Not true. The on-disk repository is now one of the more efficient
ones.
Which is a relative quality :-) Every time I update the Linux kernel
Nick Coghlan schrieb:
One thing that did happen though (which the messages from Jeremy Phil
reminded me of) is that I got a lot of direction, advice and assistance
from Raymond when I was doing that initial work on improving the speed
of the decimal module - I had the time available to run
On Tue, Mar 06, 2007 at 04:07:16PM +0100, Martin v. L?wis wrote:
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one
A.M. Kuchling schrieb:
For example, our oldest bug is http://www.python.org/sf/214033, opened
2000-09-11, and is that (x?)? is reported as an error by the SRE regex
parser; the PCRE engine and Perl both accept it. Fixing it requires
changing sre_parse, figuring out what to do (should it be
On Tue, Mar 06, 2007 at 09:53:35AM -0500, A.M. Kuchling wrote:
initial setup seems very slow: SVK is retrieving each of 54165
revisions and it'll probably take over an hour to complete.
It's even worse than that. Retrying with the trunk, SVK synced 500
revisions in about 10 minutes. We have
Eric V. Smith schrieb:
Also, it would either mean duplicating lots of code from the int
formatter, or having a formatter library that both can call. This is
because __format__ must implement all formats, including padding,
parenthesis for negatives, etc., not just the missing binary format.
Oleg Broytmann schrieb:
os.path.splitext(.pythonrc)
('', '.pythonrc')
and I think it should be
('.pythonrc', '')
Thanks, so it sounds like the patch should be accepted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Miguel Lobo schrieb:
As I am completely new to CPython development, perhaps this problem has
already been discussed and/or fixed I may have done something
incorrectly. Please let me know if that is the case.
I looked at it briefly. If I understand correctly, the proposed feature
is fine,
Martin v. Löwis schrieb:
Nick Coghlan schrieb:
One thing that did happen though (which the messages from Jeremy Phil
reminded me of) is that I got a lot of direction, advice and assistance
from Raymond when I was doing that initial work on improving the speed
of the decimal module - I had
At 04:07 PM 3/6/2007 +0100, Martin v. Löwis wrote:
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
On Tue, Mar 06, 2007, Andrew Dalke wrote:
On 3/5/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't know too many good use cases for
locals() apart from learning about the implementation I think this
might be okay.
Since I'm watching this list for any discussion on the traceback
On Tue, Mar 06, 2007, Phillip J. Eby wrote:
At 04:07 PM 3/6/2007 +0100, Martin v. L?wis wrote:
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
I consider it correct, or at the least, don't think it should be changed,
as it
A.M. Kuchling schrieb:
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 6, 2007, at 10:48 AM, Martin v. Löwis wrote:
(Of course, I don't know how long a checkout of a hypothetical Bazaar
repository would take; maybe it's not any faster.)
From my experience with git and the Linux repository, an hour is
about
I've had to blast my windows machine, as one is apparently required to
do on occasion, and I'm trying to set up subversion again. I saved my
private key file, and I can use plink -T to connect and I get:
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
and that seems correct, and
George Brandl writes:
As far as I recall, there has been nearly no one who asked for
commit rights recently, so why complain that the entry barrier is
too great? Surely you cannot expect python-dev to got out and say
would you like to have commit privileges?...
Why not? It depends on
On Tue, 6 Mar 2007, Hans Meine wrote:
Am Dienstag, 06. M?rz 2007 13:36 schrieb Martin v. L?wis:
#1115886 complains that in the file name '.cshrc', the
entire file name is treated as an extension, with no
root.
The current behavior is clearly a bug, since a leading dot does not start
On Tue, Mar 06, 2007 at 08:49:00AM -0800, Ilya Sandler wrote:
I think it's reasonable to expect that
splitext( a+. + b) == (a, .b )
for any a,b which have no dots in them...
Except for an empty 'a', in what case 'b' is the name, not the
extension. Well, 'a' cannot be empty because it's
I ran into the same problem and I'm pretty sure this cleared it up:
http://mail.python.org/pipermail/python-dev/2006-August/068369.html
Good luck,
Gustavo
On 3/5/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Andrew MacKeith schrieb:
Is there a scheduled date for the release of Python-2.5.1
On 3/6/07, Hans Meine [EMAIL PROTECTED] wrote:
The current behavior is clearly a bug, since a leading dot does not start an
extension, but marks a file as hidden. The latter is on UNIX, and while
this is different on Windows, I cannot imagine that anyone would
a) have dotfiles under that OS,
On Tue, 6 Mar 2007, [ISO-8859-1] Martin v. L?wis wrote:
Yet, in all these years, nobody else commented that the patch was incomplete,
let alone commenting on whether the feature was desirable.
Which actually brings up another point: in many cases even a simple
comment by a core developer:
Nicholas Bastin schrieb:
I've had to blast my windows machine, as one is apparently required to
do on occasion, and I'm trying to set up subversion again. I saved my
private key file, and I can use plink -T to connect and I get:
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
Ilya Sandler schrieb:
I'd also suggest that request for test cases/docs comes after
(or together with) suggestion that a feature is desirable in the first
place.
It depends. I was going through some old patches today, and came
across one that added a class to heapq. I couldn't tell (even
after
On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote:
You could try to do
ssh -vv [EMAIL PROTECTED]
and see if the debug messages mean anything to you.
My problem is that SSH works fine if you just try to do that (well,
with plink). It's subversion that doesn't seem to be working.
--
Nick
I've fixed it. It appears that there was something wrong with
Pageant, and removing my key and readding it solved the problem. The
lack of any debugging info from subversion was very helpful in solving
this problem.. :-)
Thanks for the help from those who responded.
--
Nick
At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote:
given a list of file names, classify them for display (the
way the Windows explorer works, and similar file managers).
They use MIME databases and the like, and if they are unix-ish,
they probably reject the current splitext
Nick I don't know whether or not there is anything specific we can do
Nick to encourage that kind of coaching/mentoring activity, but I know
Nick it was a significant factor in my become more comfortable with
Nick making contributions.
Martin While there was no explicit
On 3/6/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote:
given a list of file names, classify them for display (the
way the Windows explorer works, and similar file managers).
They use MIME databases and the like, and if they are
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
1. Public identification will not help, because:
2. most code isn't in the responsibility of anybody (so publically
identifying responsibilities would leave most code unassigned), and
3. for the code that has some
I'm trying to find the Python library binaries associated with a given
python executable.
If I look at the help for sys.prefix and sys.exec_prefix
import sys; help(sys)
I see:
prefix -- prefix used to find the Python library
exec_prefix -- prefix used to find the machine-specific
At 02:08 PM 3/6/2007 -0500, Nicholas Bastin wrote:
The notion of an unnamed file with an extension I think would be very
odd to most people.
Clearly, we all think that most people are like ourselves. :)
I think that for someone with a Windows/DOS background, that's *exactly*
what .cshrc looks
On 3/6/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
It's *useful* to classify e.g. .svn directories or .*rc files by their
extension
I respectfully disagree. When trying to find directories named .svn or
files named .bashrc, I do
filename in ('.svn', '.bashrc')
because I don't expect
dustin In summary, create a layer of volunteer, non-committing
dustin maintainers for specific modules who agree to do in-depth
dustin analysis of patches for their areas of expertise, and pass
dustin well-formed, reviewed patches along to committers.
One problem with this sort
On Tue, Mar 06, 2007 at 01:03:39PM -0600, [EMAIL PROTECTED] wrote:
Could the Summer of Code be used as a vehicle to match up current developers
with potentially new ones? The svn sandbox (or a branch) could serve as a
place for developers to get their feet wet. Perhaps Raymond can comment on
Nicholas Bastin schrieb:
I've had to blast my windows machine, as one is apparently required to
do on occasion, and I'm trying to set up subversion again. I saved my
private key file, and I can use plink -T to connect and I get:
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to worry about when writing cross-version code.
Windows
On Tue, Mar 06, 2007 at 01:51:41PM -0600, [EMAIL PROTECTED] wrote:
dustin In summary, create a layer of volunteer, non-committing
dustin maintainers for specific modules who agree to do in-depth
dustin analysis of patches for their areas of expertise, and pass
dustin
Neal Norwitz wrote:
I recognize there is a big problem here. Each of us as individuals
don't scale. So in order to get stuff done we need to be more
distributed. This means distributing the workload (partially so we
don't burn out). In order to do that we need to distribute the
As I am completely new to CPython development, perhaps this problem has
already been discussed and/or fixed I may have done something
incorrectly. Please let me know if that is the case.
I looked at it briefly. If I understand correctly, the proposed feature
is fine, but lacks a test case.
Terry Reedy wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to worry about when writing
The 5:1 patch review is a good idea -- but what is the procedure for
reviewing a patch?
I often comment on patches. Does this count as a review? Would
anyone know if it did?
If I were going through five at the same time, and I had a sixth to
push, I could post here. Normally, I just make a
Guido van Rossum wrote:
- I'll modify urlopen for it to accept a socket_timeout parameter,
default to None
I'd call it timeout. There can't really be much ambiguity can there?
Yes and no. For example, if I do a
``urllib2.urlopen(ftp://ftp.myhome.com.ar/blah.txt;, timeout=10)``, the
timeout
Phillip J. Eby schrieb:
I know I've written code like this that *depends* on the current
behavior. It's *useful* to classify e.g. .svn directories or .*rc files
by their extension, so I'm honestly baffled by the idea of wanting to
treat such files as *not* having an extension (as opposed
At 02:55 PM 3/6/2007 -0500, Terry Reedy wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to
David Abrahams schrieb:
I'm trying to find the Python library binaries associated with a given
python executable.
This really isn't a python-dev question; please use python-list
(news:comp.lang.python) instead. Please take a look at sys.path.
1. I think the documentation for sys and
Jim The 5:1 patch review is a good idea -- but what is the procedure
Jim for reviewing a patch?
Jim I often comment on patches. Does this count as a review? Would
Jim anyone know if it did?
I believe review can mean a few things:
* Comments. Reviewing the code does it
Martin v. Löwis wrote:
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
+1 on the behavior. However, the patch is special-casing a leading dot;
it would still fail on splitext(..). If we're gonna fix the bug, I'd
rather
On 3/6/07, Facundo Batista [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
- I'll modify urlopen for it to accept a socket_timeout parameter,
default to None
I'd call it timeout. There can't really be much ambiguity can there?
Yes and no. For example, if I do a
Jim Jewett schrieb:
The 5:1 patch review is a good idea -- but what is the procedure for
reviewing a patch?
I often comment on patches. Does this count as a review?
Sure. Ideally, a review should bring the patch to an accept-or-reject
state, i.e. it should lead to a recommendation to the
Larry Hastings schrieb:
Hope this helps,
Indeed it does! After all this discussion, a documentation clarification
is certainly in order, but I can work that out myself.
Thanks,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
on Tue Mar 06 2007, Martin v. Löwis martin-AT-v.loewis.de wrote:
David Abrahams schrieb:
I'm trying to find the Python library binaries associated with a given
python executable.
This really isn't a python-dev question; please use python-list
(news:comp.lang.python) instead.
I wrestled
Terry Reedy schrieb:
It would also be helpful if the new tracker system could produce a list of
module-specific open items sorted by module, since that would indicate
modules needing attention, and I could look for a batch that were
unassigned.
The new tracker will initially have the same
At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote:
It's unfortunate, of course, that people apparently relied on
this behavior
I was going to say it's the *documented* behavior, but I see that the
documentation is actually such that it could be interpreted either way.
However, since it's not
David Abrahams schrieb:
on Tue Mar 06 2007, Martin v. Löwis martin-AT-v.loewis.de wrote:
David Abrahams schrieb:
I'm trying to find the Python library binaries associated with a given
python executable.
This really isn't a python-dev question; please use python-list
(news:comp.lang.python)
On 3/5/07, Facundo Batista [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
developers and people who develop their own software. I would like to hear
from people who have concrete doubts about this upgrade path. I don't mean
Disclaimer: I'm not involved in Py3k, and not even tried it once.
Phillip J. Eby schrieb:
At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote:
It's unfortunate, of course, that people apparently relied on
this behavior
I was going to say it's the *documented* behavior, but I see that the
documentation is actually such that it could be interpreted either
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Windows did not allow .xxx as a filename in my attempts, so this case
seems
| irrelevant there.
|
| Huh? .xyz files work fine on Windows.
Tim G. explained that Explorer, which I tried, is for whatever reason
stricter
On 2/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
2to3 should take great care _tell_ you when it fails. One concern I have is
that the source translation may subtly alter the *semantics* of unit test
code, so that the tests are no longer effective and do not provide adequate
coverage.
Andrew Dalke wrote:
def __init__(self, prec=None, rounding=None,
traps=None, flags=None,
_rounding_decision=None,
Emin=None, Emax=None,
capitals=None, _clamp=0,
_ignored_flags=None):
...
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy schrieb:
| It would also be helpful if the new tracker system could produce a list
of
| module-specific open items sorted by module, since that would indicate
| modules needing attention, and I could look
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's a new PEP that's the outgrowth of work Brett Cannon and I did
at PyCon. Basically we were looking for a way to allow for forward
compatibility with PEP 3108, which describes a reorganization of the
standard library. PEP 364 is for
I think there are various good arguments that the current behavior of
splitext isn't optimal. But. these don't feel strong enough to me to
break existing code or to force people who happen to be in the know to go
hunt down and review old code etc. I don't see the point in doing that,
just to
Tim Lesher wrote:
FWIW, all of the standard Windows functions from the Microsoft CRT
(_splitpath) to the Shell API (PathRemoveExtension) to the CLR
(System.IO.Path.*) believe that .cshrc is the extension of the
filename .cshrc.
I'm not sure if that's an argument for or against the patch,
On 3/6/07, Greg Ewing [EMAIL PROTECTED] wrote:
Although you can get a similar effect now by doing
def __init__(self, **kwds):
args = dict(prec=None, rounding=None,
traps=None, flags=None,
_rounding_decision=None,
1 - 100 of 123 matches
Mail list logo
