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 ov
#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? Opini
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 e
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 i
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 ke
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
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 b
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 form
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
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,
A.M. Kuchling schrieb:
> I'm happy to write up a wiki page describing how to use SVK to set up
> your own mirror of the Python SVN. However, trying it now, the
> initial setup seems very slow: SVK is retrieving each of 54165
> revisions and it'll probably take over an hour to complete.
If it help
Phillip J. Eby schrieb:
> 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.
Now it's becoming difficult: several people in f
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
aft
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 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 oppo
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 conf
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
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
http://mail.pyt
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 sa
David Abrahams schrieb:
> on Tue Mar 06 2007, "Martin v. Löwis" 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 quest
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
David Abrahams schrieb:
>> That absolutely cannot be the case. Python is open source, you have
>> *everything* you need to answer this question.
>
> That assumes this is one of those questions to which "use the source"
> is applicable. I think answering it requires some understanding of
> intentio
Jim Jewett schrieb:
> It has been quite a while since I worried about my own patches going
> stale; I just want to know how my review time can be more useful.
>
> Once a committer has already decided to look at a patch, comments may
> make the next step easier.
>
> But is there anyway to flag an
Barry Warsaw schrieb:
> Jira had a way of automatically assigning certain categories to certain
> people. I think the term was project leader or some such. Of course,
> this didn't mean that someone else couldn't fix the bug or that the bug
> couldn't be reassigned to someone else, but at leas
[EMAIL PROTECTED] schrieb:
> More to the point, we know the cost, what's the benefit? Is there any
> sort of bug that it is likely to prevent in *new* code?
Yes. People are more likely to classify the file as "no extension",
which more likely meets the user's expectation. Also, it won't happen
Terry Jones schrieb:
> I do think the behavior can be improved, and that it should be fixed, but
> at a place where other incompatible changes will also be being made,
Indeed, 2.6 is such a place. Any feature release can contain
incompatible behavior, and any feature release did contain incompati
Ron Adam schrieb:
> But the tracker needs to be able to actually track the status of individual
> items for this to work. Currently there's this huge list and you have to
> either wade though it to find out the status of each item, or depend on
> someone bring it to your attention.
Well, the
Nilton Volpato schrieb:
> My Google Summer of Code project was just about this, and I
> implemented a lot of nice features. These features include: file-like
> access to zip member files (which solves your problem, and also
> provides a real file-like interface including .read(), .readline(),
> etc
Giovanni Bajo schrieb:
> On 06/03/2007 10.52, Martin v. Löwis wrote:
>
>> I can't see that the barrier at contributing is high.
>
> I think this says it all. It now appears obvious to me that people
> inside the "mafia" don't even realize there is one.
Han-Wen Nienhuys schrieb:
> 1608267 - added comment, asking for explanation. looks bogus.
> 1608579 - problem analysis + solution looks good
> 1507247 - I can reproduce the problem it tries to fix. Fix looks ok.
> 1520879 - trivial fix; should go in. disregard the comment about relative
> --prefix
Paul Moore schrieb:
> 1. Open a new patch, with your recommended changes.
I'd like to second this. If you are creating a patch by responding in a
comment, it likely gets ignored.
> 2. Address the comments made against Tony's patch, in yours.
> 3. Add a recommendation to Tony's patch that it be
Josiah Carlson schrieb:
>> Now it's becoming difficult: several people in favor, some opposed...
>
> What about changing the semantics of splitext and creating a new
> function (available on all platforms) that does what the Windows version
> currently does?
>
> For people who want the one semant
Titus Brown schrieb:
> Hi, I just wanted to interject -- when I used the word "mafia", I meant
> it in this sense:
>
> """
> Informal. A tightly knit group of trusted associates, as of a political
> leader: [He] is one of the personal mafia that [the chancellor]
> brought with him to Bonn.
> """
>
Facundo Batista schrieb:
> I finally understood the problem, and build python from the repository,
> and made the tests from *this* python (actually, this was an easy step
> because I'm on Ubuntu, but *I* would be dead if working in Windows, for
> example).
>
> Ok. *Me*, that I'm not ashame of ask
Georg Brandl schrieb:
>
> Of course, the channel would have to be made an "official" Python development
> tool and advertised on e.g. the website. Also, it couldn't hurt if some of the
> other devs would frequent it too, then :)
>
I definitely won't: I don't use IRC (or any other chat infrastruct
Andrew Bennetts schrieb:
> Glyph's proposing that rather than risk breaking existing code (and in the
> worst
> possible way: silently, giving wrong answers rather than exceptions), we
> examine
> what benefits changing splitext would bring, and see if there's a way to get
> those benefits withou
Giovanni Bajo schrieb:
I can't see that the barrier at contributing is high.
>>>
>>> I think this says it all. It now appears obvious to me that people
>>> inside the "mafia" don't even realize there is one. Thus, it looks
>>> like we are all wasting time in this thread, since they think th
Josiah Carlson schrieb:
> Because we should refuse the temptation to guess, what about:
>
> Rename the posix splitext to X (for some X), and offer a function with
> identical functionality to the posix variant under win32, also available
> as X for that platform.
>
> Rename the (current) win32 sp
BJörn Lindqvist schrieb:
> (This might be a silly question..)
>
> In the dev stdlib reference there are lots of pages in which all text
> is in italics. Such as all chapters after chapter 18.
Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts
between 18.17 and 18.17.1. However, look
Scott David Daniels schrieb:
> c) Given a filename, make an appropriately named associated file.
> pyo_name = os.path.splitext(name)[0] + '.pyo'
> This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
Indeed, somebody found that people apparently do
back_name = spl
Alexey Borzenkov schrieb:
> I don't understand only one thing, why do people need new functions?
> You can anticipate the change today, and write functions that do
> exactly what you need no matter which way (current or proposed) python
> implements:
Indeed, that's also true. When people actually
Collin Winter schrieb:
> Was any course of action ever decided on for this issue, or was the
> consensus that it would break too much code? If the latter, what about
> making the change for Python 3000?
Neither, nor. If a grand renaming is not feasible, I'd atleast do
something about object.h for
[EMAIL PROTECTED] schrieb:
> The real issue I have here is one of process. Why is it that PJE (or
> any python user who wishes their code to keep working against new
> versions of Python) must frequent python-dev and convince you (or
> whatever Python developer might be committing a patch) of e
Grig Gheorghiu schrieb:
> Titus and I are thinking about mentoring a Google Summer of Code
> project that would use the 'buildbot try' feature: set up a bunch of
> buildbot slaves and set them up so sending them a patch will trigger a
> checkout of the latest Python svn, followed by the application
Anthony Baxter schrieb:
> What do people think about the idea of a version-specific PYTHONPATH
> environment variable?
I agree with Guido. I normally need an application-specific PYTHONPATH,
and I do that by editing the start script adding a sys.path.append
into it (these days, Python application
Phillip J. Eby schrieb:
> At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote:
>> In the case that triggered the discussion, the change implemented
>> was not an incompatible change, because the new implementation still
>> met the old specification (which, of course, was undersp
Christian Heimes schrieb:
> BJörn Lindqvist schrieb:
>> I think it should be a ValueError, given that the programmer is very
>> likely to further use the returned timestamp to for example insert
>> stuff in a database. Unix timestamps are not unambiguously defined for
>> any years other than 1970 t
BJörn Lindqvist schrieb:
>> If you extend the range to 64 bits there's no problem: the first
>> should print 3250368, the second -2208988800.
>
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff i
Collin Winter schrieb:
>
> Any thoughts on this?
There are know problems comparing durations (e.g. is 30 days more
or less than a month?). For time stamps, there is no issue. For
calender dates, there are again problems, in particular with time
zones.
What I don't know (because I never used it)
Michael Foord schrieb:
> Hello all,
>
> I realise that this may be more relevant to Python ideas, in which case
> feel free to ignore this (and my apologies).
>
> I occasionally see code looking (something) like :
>
>
> calling_scope = sys._getframe(1).f_globals['__name__']
>
> This looks and
Patrick Maupin schrieb:
> Although it is often quite easy to find and download a module for use
> with a prior version of Python, it would be really convenient if all
> of these modules were bundled up together and available as a single
> download, especially when it comes to Windows users and exte
[EMAIL PROTECTED] schrieb:
> This does raise an interesting question, though, since I'm about to get
> into PEP authorship myself. Have I missed an official way to propose
> alternatives or resurrect a languishing PEP?
See PEP 1. The PEP champion is obliged to integrate feedback into the
PEP,
Rajstennaj Barrabas schrieb:
> I have an application which runs on 2.4.4 and is known not to run on 2.4.1 or
> 2.5, and I'm trying to install 2.4.4 from the website.
>
> Whenever I download and compile the 2.4.4 sources, the executable shows up as
> 2.4.1 which will not work for my application.
>
> Sorry for the repetition, but since nobody has commented on patch
> 1644818 for about a week I thought perhaps I should ask again.
>
> Is there anything I need to do before the patch is ready for inclusion?
No; basically, you just need to be patient now. Do you have an urgent
need to get this
Miguel Lobo schrieb:
> Also, seeing that there are almost 400 open patches in the patch
> tracker, I'm concerned that this patch will be forgotten and left to
> rot, which would be a pity IMO.
Of course, the submitters of the 300 other patches say the same. It is
just too difficult to catch up,
Miguel Lobo schrieb:
> Personally, I can't apply it as-is right now, since a) I would have to
> check that the test case conditionalization works fine, and b) I would
> have to come up with a patch for the Windows build process.
>
>
> Sorry, I couldn't understand the second point. Wh
Miguel Lobo schrieb:
> My own patch does not include documentation. I assume documentation
> would only be needed for patches that add new functionality (as opposed
> to fixing problems)?
Typically, yes. If the bug fix would also change the behavior of
existing programs, that change should be d
Miguel Lobo schrieb:
> I need to integrate the extra test file into a project file (probably
> pythoncore).
>
>
> The change to pythoncore.vcproj is already in the patch I posted.
> Otherwise I wouldn't have been able to run my test under Windows.
Ah, ok, I misremembered. It is the UNI
Miguel Lobo schrieb:
> It won't benefit the Python core either, because we just don't use
> builtin submodules. In fact, I find the notion of builtin submodules
> somewhat strange.
>
>
> Please excuse my curiosity, but why do you find it strange?
Normally, the builtin modules are the
Miguel Lobo schrieb:
> Perhaps one example would help to clarify what I mean. I see that there
> is an xml.parsers.expat module, with the following content:
>
>
>
> """Interface to the Expat non-validating XML parser."""
> __version__ = '$Revision: 17640 $'
>
> from pyexpat import *
>
>
Georg Brandl schrieb:
> Patch #1517947 suggests adding an assert for these.
>
> Is that acceptable or just considered a drop in ocean?
I think it's pointless. If they ever be NULL, the INCRE/DECREF
will crash right away, anyway, so you'll certainly notice.
As you will have a debug build when the
Phillip J. Eby schrieb:
> This backwards-incompatible change is therefore contrary to policy and
> should be reverted, pending a proper transition plan for the change
> (such as introduction of an alternative API and deprecation of the
> existing one.)
I'm clearly opposed to this proposal, or e
Phillip J. Eby schrieb:
> That much is obvious. But I haven't seen any explanation as to why
> explicitly-documented and explicitly-tested behavior should be treated
> as a bug in policy terms, just because people don't like the documented
> and tested behavior.
It's not "just" that people dis
Thomas Wouters schrieb:
> However, changing documented, tested behaviour without warning gives
> Python an even worse name. I agree with PJE that the change is the wrong
> thing to do, simply because it sets (yet another) precedent. If
> providing an alternate API with clearer semantics is too '
Delaney, Timothy (Tim) schrieb:
> A change to the documented behaviour should require a __future__
> import for at least one version. That's even assuming that the change
> is desireable (I don't believe so). We have multiple anecdotes of
> actual, existing code that *will* break with this change.
Phillip J. Eby schrieb:
> And yet, that "incorrect" behavior was clearly intended by the author(s)
> of the code, test, and docstrings.
>
> As it happens, Guido wrote that code (16 years ago) and the docstring (9
> years ago), in the case of the posixpath module at least.
I don't find it that c
[EMAIL PROTECTED] schrieb:
> >This backwards-incompatible change is therefore contrary to policy and
> >should be reverted, pending a proper transition plan for the change (such
> >as introduction of an alternative API and deprecation of the existing
> one.)
>
> I hope that this is true, but *
I just proposed to implement thread cancellation for the SoC.
Is there any prior work where one could start?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Jean-Paul Calderone schrieb:
>> I inferred from Martin's proposal that he
>> expected the thread to be able to catch the exception. Perhaps he can
>> elaborate on what cleanup actions the dying thread will be allowed to
>> perform.
>
> Perhaps he can. Hopefully, he can specifically address these
Phillip J. Eby schrieb:
> If it weren't for the code breakage, I'd be in favor too. That's not the
> point.
>
> The point is that how can Python be stable as a language if precedents can
> be reversed without a migration plan, just because somebody changes their
> mind? In another five years,
[EMAIL PROTECTED] schrieb:
> Just in case it's not clear from the other things I've said: this is a
> terrible, terrible idea, and I am shocked that it is even being
> *considered* for inclusion in Python. As a foolish youth, I wasted many
> months trying to get a program that used Java's (then
Steve Holden schrieb:
> This is not "prevarication", it's a serious discussion about how such
> issues should be managed. The current glaring lack is of a sound
> decision-making process. Such breakage-inducing change should be
> reserved for major versions (as was the fix to the socket address
> This particular change looks like gratuitous breakage, no matter how
> sound the reasons for it, and putting it in to 2.6 with 3.0 "just around
> the corner" (though not for production purposes) is guaranteed to upset
> some people and cause adverse reaction.
>
> This is not "prevarication",
Mike Krell schrieb:
> When I first needed to use splitext in my code, I tested the relevant
> corner case in question at the interactive prompt. I also read the
> docstring which explicitly documented the behavior. I then wrote my
> code accordingly.
Can you show us the relevant fragment of your
Mike Krell schrieb:
> FWIW, I agree completely with PJE's and glyph's remarks with respect
> to expectations of stability, especially in a minor release.
Not sure what you mean by "minor release". The change isn't proposed
for the next bug fix release (2.5.1), but for the next major release
(2.6
Mike Krell schrieb:
> Sure:
>
> for f in files:
> try:
> (root, ext) = os.path.splitext(f)
> os.rename(f, '%s.%s%s' % (root, index, ext))
> except OSError:
> die('renaming %s failed' % f)
Thanks! Looking more closely, it's not entirely clear
[EMAIL PROTECTED] schrieb:
> >Not sure what you mean by "minor release". The change isn't proposed
> >for the next bug fix release (2.5.1), but for the next major release
> >(2.6). See PEP 6.
>
> Common parlance for the parts of a version number is:
> major.minor.micro
> See:
>
> http:
Georg Brandl schrieb:
> As a sidenote, this item should be included in the 2.6 "What's new"'s
> "porting"
> section.
>
> Perhaps it would be a good "policy" to automatically list potentially breaking
> fixes there instead of rolling off that task to Andrew.
I would do that, except that Andrew ex
Stephen Hansen schrieb:
> And it'd be so easy to do it in a way which wouldn't be silent... just
> throw out a warning, and defer the actual change until the next release.
I disagree that it easy to do that. Implementation-wise, it probably is.
However, I feel that warnings have a *very* high cos
[EMAIL PROTECTED] schrieb:
> However, the decision was a bad one regardless of the existing policy,
> and sets a bad precedent while we are discussing this policy. I could
> be wrong, but I think it would be reasonable to assume that if Martin
> strongly supports such a change, Martin would opp
Mike Krell schrieb:
> Here is a point of confusion. Bear in mind I'm running this under
> windows, so explorer happily reports that ".emacs" has a type of
> "emacs". (In windows, file types are registered in the system based
> on the extension -- all the characters following the last dot.
Is it
Phillip J. Eby schrieb:
> Some other options:
>
> 1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
> 2. Add an optional flag argument to enable the new behavior
How would that help backwards compatibi
Thomas Wouters schrieb:
> Hah, everyone agree? They weren't agreeing when you changed it, either
> :) But no, we don't add a warning *and* change the API. We add a warning
> *about* changing the API. 2.6 sees no semantic change, just a warning
> when os.path.splitext is used on a dotfile with no
Patrick Maupin schrieb:
> The worst part is, if they are relying on that specific behavior and have
> to rely on the new specific behavior, and want to support old and new
> versions of Python, they are potentially left with some very unattractive
> options -- check the Python version to figure out
A.M. Kuchling schrieb:
> Where should I add a note about this: a comment at the top of
> whatsnew.tex, maybe?
That would be good.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
Steve Holden schrieb:
>> Somebody has pointed out that it is fairly easy to write a wrapper
>> around splitext that explicitly produces the old behavior on all
>> versions, or the new behavior on all versions, depending on what
>> precisely is desired. Users that have coded for a specific behavio
Mike Krell schrieb:
> On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> If they pass the flag to the function, the code will stop running on
>> 2.5 and earlier. This is worse than having code that works on all
>> versions. This is also whz
Patrick Maupin schrieb:
> On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Assuming the current behavior is a bug (which I still believe to be
>> the case), in order to actually make use of the bug fix, you have to
>> pass the parameter. This will
Tony Meyer schrieb:
> ISTM that there is value in submitting a patch (including tests and
> documentation, and making appropriate comment in related patches), even
> if that is all that is done (i.e. no follow-up).
That's certainly, absolutely, true. It's also true that there are very
many kind
Guido van Rossum schrieb:
> And Martin, if I decide that the change should be
> rolled back, will you be okay with that?
Certainly. I would wish somebody contributed a documentation patch
pointing out that specific detail in the documentation (and in
the process making the documentation match the
Phillip J. Eby schrieb:
> Actually, he asked first if we *want* him to make one, and my answer to
> that is above: I don't think it's necessary. Like Martin, I believe we are
> within sight of a consensus. And I think that's better for Python and
> Python-Dev than dragging Guido into it.
I a
> Specifically, however, I would prefer to see it without the warning and
> future change, as I don't think it provides any real benefit. Either
> way, some people will have to use a keyword to get what they want, so
> making a change seems unnecessary.
>
> However, if we have to change someth
Jay Parlar schrieb:
> 1) Who would most likely mentor this project?
As Brett says, it all depends on the applications we receive and
those that get accepted. That said, it might be me.
> 2) I've never worked in the core before (but have been using Python as
> my primary language for about 6 years
Ronald Oussoren schrieb:
>> I don't understand. Example?
>
> You conveniently ignored my other arguments ;-).
>
> Given a splitext that ignores leading dot's the following function doesn't:
> # from os.path import *
> def splitext2(path):
> dn = dirname(path)
>
> I have to cross compile Python to run on Arm processor based MontaVista
> Linux.
> If anyone has tried this already, please let me know the procedure.
Dear Kiran,
The python-dev mailing list is for the development *of* Python, not for
the development *with* Python; use python-list@python.org
>> old and had not been touched in ages. Hopefully you will be able to
>> easily port this over to the new tracker once it's up (that should
>> happen 2-4 weeks after 2.5.1 is released).
>
> You can be sure I'll port it...
When you do, make sure you take a look at roundup's search facilities.
Ro
> test_posixpath is failing in: test_relpath
This is due to #1339796, r54419. I left a comment in the tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
> Patch 1490190 causes test_posix to fail on Tru64 due to chflags().
I have a potential fix for that in the tracker.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
> class List(list):
> def append(self, x):
> print x
> List.append(self, x) # What is the C equivalent of this call?
Always literally what you write in Python (assuming you meant
list.append):
PyObject_CallMethod(PyList_Type, "append", "OO", self, x);
HTH,
Martin
_
2001 - 2100 of 5277 matches
Mail list logo
