Hi Nick,
If there is no enormous difficulty in maintaining compatibility, I think
the usual deprecation process should be followed. We don’t know who is
using pydoc as a library, so let’s play safe and not risk breaking their
code (especially considering that it must not have been easy to write
c
> Author: r.david.murray
> New Revision: 86327
>
> Log: #10321: Add support for sending binary DATA and Message objects to
> smtplib
>
> Modified: python/branches/py3k/Doc/includes/email-mime.py
> ==
> # Send the email
Hello Senthil
> Author: senthil.kumaran
> New Revision: 86348
> Log: Fix Issue10205 - XML QName error when different tags have same QName.
>
> Modified:
>python/branches/py3k/Lib/test/test_xml_etree.py
>python/branches/py3k/Lib/xml/etree/ElementTree.py
Shouldn’t this include an entry in
>> Shouldn’t this include an entry in NEWS and maybe in ACKS?
> It was a very simple bug fix (caused due to an overlook initially), so
> did not add NEWS/ACKS. For features, larger fixes or complete patches,
> I the add NEWS and ACKS as appropriate.
Thanks for the reply. Now I’m unsure about the
> I just follow Guido's own personal rule: if the fix required thought
> they should go into Misc/ACKS.
Okay. Same rule for NEWS?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
> We may also revisit the rules used by help() to decide what to include
> on the auto-generated module implementation. Note that currently
> help() output excludes names not in __all__ is the module has __all__
> defined. While I advocated this rule earlier in this thread, I now
> Consider the r
> Excluding a builtin name from __all__ sounds like a perfectly sensible
> idea, so even if it wasn't deliberate, I'd say it qualifies as
> fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d put open in __all__.
Regards
__
> I don't understand all the worry about sys.subversion. It's not like
> it's useful to anybody else than us, and I think it should have been
> named sys._subversion instead. There's no point in making API-like
> promises about which DVCS, bug tracker or documentation toolset we use
> for our workf
Hello
> cgitb.enable(0,"d:\temp")
Isn’t that expanded to “d:emp”?
___
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
> Author: nick.coghlan
> New Revision: 86633
>
> Issue #10220: Add inspect.getgeneratorstate(). Initial patch by Rodolpho
> Eckhardt
>
> Modified: python/branches/py3k/Doc/library/inspect.rst
> ==
> --- python/branches/p
Hi,
I think this bug is related: http://bugs.python.org/issue1294959
“Problems with /usr/lib64 builds.”
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
> Author: senthil.kumaran
> New Revision: 86748
>
> Log:
> Experimental - Transparent gzip Encoding in urllib2. There should be a good
> way to deal with Content-Length.
Cool feature! But...
> Modified:
>python/branches/py3k-urllib/Lib/http/client.py
>python/branches/py3k-urllib/Lib/url
>>> Modified:
>>>python/branches/py3k-urllib/Lib/http/client.py
>>>python/branches/py3k-urllib/Lib/urllib/request.py
>> No tests? Misc/NEWS? :)
>
> Note that this is work in a separate branch.
Ah, didn’t notice that! Senthil replied as much in private email:
> That was in a different
Hello,
> Author: senthil.kumaran
> Log:
> Mouse support and colour to Demo/curses/life.py by Dafydd Crosby
>
> Modified:
>python/branches/py3k/Demo/curses/life.py
Okay, this time I’m reacting to the right branch
> Modified: python/branches/py3k/Demo/curses/life.py
>
Hello,
> Please comment with any changes you want to see, or speak in
> favor or against this PEP.
How to get a diff between py3k and this branch?
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Good morning python-dev,
PEP 291 (Backward Compatibility for Standard Library) does not seem to
take Python 3 into account. Is this PEP only relevant for the 2.7
branch?* If it’s supposed to apply to 3.x too, despite the view that
3.0 was a clean break, what does it mean to have a module that is
> On Thu, Dec 2, 2010 at 12:41 PM, raymond.hettinger
> wrote:
>> +A more general approach is to arrange the weights in a cumulative
>> probability
>> +distribution with :func:`itertools.accumulate`, and then locate the random
>> value
>> +with :func:`bisect.bisect`::
>> +
>> +>>> choices, we
> even without having any changes in distutils it would make sense to know if
> an
> extension can be built with the restricted ABI, so maybe it is better to
> defer
> any changes to the extension soname, and provide a check for an extension if
> it
> conforms to the restricted ABI, even if t
Hi Prashant,
Python 3 support in distutils2 is not entirely finished, it’s an
interesting and challenging task.
Another idea: convert the python.org internal scripts to use Python 3,
for example starting with patches for http://code.python.org/hg/peps/ .
This would not have any impact on the comm
Le 02/12/2010 23:17, Martin v. Löwis a écrit :
> Before the freeze, distutils was unmaintained (i.e. before you started
> maintaining it), but people who want to improve it gradually atleast
> could. Now gradual improvements are also banned, so it's not only
> unmaintained, but I can't even provide
Hi everyone,
I have sketched a workflow guide on
http://wiki.python.org/moin/Distutils/FixingBugs
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
Le 03/12/2010 08:31, Martin v. Löwis a écrit :
>> I wonder what your definition of “unmaintained” is.
> In this specific case: doesn't get feature requests acted upon.
Thanks for clarifying. I think that’s a stretch, but I see your meaning
now.
>> Sure, distutils is not as well-maintained as oth
> But I'm not interested at all in having it in distutils2. I want the
> Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
version. If you implement it in distutils2, you have very good chances
to get it for 3.3
Le 04/12/2010 17:55, Tarek Ziadé a écrit :
> On Sat, Dec 4, 2010 at 12:27 PM, Antoine Pitrou wrote:
>>> It seems like it'd be a good idea to start integrating distutils2 into
>>> python trunk immediately after the 3.2 branch is cut, then.
>>
>> +1 from me.
>
> +1 too.
+1, and I take responsibil
Hello,
Three messages sent in reaction to python-checkins email have not got
any reply so far, so I’m resending them.
Regards
Nick, in reaction to the reprlib.recursive_repr commit:
>> > +# Can't use functools.wraps() here because of bootstrap issues
>> > +wrapper.__module__ = g
Hello,
> Author: ronald.oussoren
> New Revision: 87118
> Log: Two small changes to adjust framework builds to the new stable ABI
>
> Modified: python/branches/py3k/Mac/BuildScript/build-installer.py
> ==
> +LDVERSION=
Hello,
> Author: raymond.hettinger
> Date: Mon Nov 29 02:38:25 2010
> New Revision: 86855
> Log: Do not add an obsolete unittest name to Py3.2.
> Modified: python/branches/py3k/Lib/unittest/case.py
> -# Old name for assertCountEqual()
> -assertItemsEqual = assertCountEqual
When we merge
Le 09/12/2010 19:42, Guido van Rossum a écrit :
> Given that it's in 3.2b1 I'm okay with keeping it. That's at best a
> +0. [...]
> though I still don't like that the registries for transforms and
> codecs use the same namespace. Also bytes-bytes and
> string-string transforms use the same namespa
Le 09/12/2010 11:57, Michael Foord a écrit :
> unittest2 will continue to track changes in unittest. A 0.6.0 release is
> planned, with feature parity with the version of unittest in Python 3.2.
All right. We’ll just run a sed over our tests and bump our required
unittest2 version. Thanks for th
Hi,
Original discussion for the sysconfig module was short:
http://mail.python.org/pipermail/python-dev/2009-May/089520.html
Tarek will reply better, but I think the issue to solve was to move
sysconfig out of distutils, improving its API a bit in the process but
not overhauling it completely. A
Hi,
I suggest to replace “error” with “event” in the module doc synopsis.
Regards
___
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/archi
>> -option. Run :program:`python regrtest.py -uall` to turn on all
>> +option. Run :program:`python -m regrtest -uall` to turn on all
>
> Shouldn't this be `python -m test.regrtest`, or even just `python -m test`?
It should :) I was about to fix just that but then noticed I could
remove more ref
> Author: lukasz.langa
> New Revision: 87299
>
> Log:
> Broken ConfigParser removed, SafeConfigParser renamed to ConfigParser.
> Life is beatiful once again.
IIIUC, this change makes bugs requesting use of SafeConfigParser in
distutils and logging obsolete.
> @@ -1139,6 +1122,6 @@
>
> if __nam
> The diff looks good to me.
Committed as r87300, thank you sir!
___
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.
Hi,
I noticed that changes related to PEP 3147 and PEP 3149 in Doc haven’t
been accompanied by versionadded/versionchanged directives.
Is that on purpose, meaning that everyone should be aware of these PEPs
when reading 3.2 docs, or just an oversight?
Regards
___
> It's an oversight. The changes should be accompanied by version* directives.
> I see you already committed a change for compileall.rst - thanks for that!
> Please feel free to add anything you find missing or submit a bug report and
> assign it to me.
The PEP 3149 commits did not touch Doc, apa
Hi,
Thanks for double-checking.
When I first looked into compileall, I opened
http://bugs.python.org/issue10454 where I state that I find the
description of those options unclear or even not understandable, so your
diagnosis that I just copied text is right.
A rewrite to fully cover the module f
Le 18/12/2010 16:33, Oleg Broytman a écrit :
>This is quite a known problem, not specific to Python. Locale
> settings are global for a process, and this is one of the thousands
> reasons why locale is considered so horrible.
>ICU is perhaps the only way around the problem.
Babel rocks: ht
Le 23/12/2010 20:55, Antoine Pitrou a écrit :
>> def __index__(self):
>> -"""index(self)"""
>> +"""someobject[self]"""
>
> This is misleading as to what the method actually does,
Really? Unless I misunderstood the docs, __index__ is used when the
object is used as an index (o
> faulthandler is a module: enable the handler is simple as "import
> faulthandler".
That sounds like a source of unwanted behavior (aka problems) if the
handler is enabled by “pydoc faulthandler” or by a pkgutil walk. You
may want to consider using a function to enable the functionality (and
add
Le 24/12/2010 02:08, Nick Coghlan a écrit :
> On Fri, Dec 24, 2010 at 4:41 AM, eric.araujo
> wrote:
>> Fix small inaccuracy: there is no index function
>
> Yes, there is, it just isn't a builtin - it lives in the operator module.
Defining object.__index__ with operator.index seems pretty circula
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
a merge tool? I for one immensely like Mercurial’s merge and utterly
dislike S
Le 07/01/2011 19:39, Brian Curtin a écrit :
> On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
>> Module split:
>> try to get all issues for 'os' module
> No solution for this right now, but people have suggested that we add
> drop-downs for each module. I'm -0 on that.
I proposed that on
> I would like to advocate again for the removal of the "unit test
> needed" stage on the tracker, which regularly confuses our triagers
> into thinking it's an actual requirement or expectation from
> contributors and bug reporters.
Speaking as a bug triager:
+1 to rename it “test needed”
+1 to r
>> +1 to rename it “test needed”
>> +1 to remove it
I meant either one would be an improvement.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
Le 10/01/2011 20:11, Eli Bendersky a écrit :
> Perhaps a different wording would be preferred to removal. Suppose a
> reviewer accepts a patch but asks for a test before committing it.
Well, we usually forewarn that a patch should include tests and docs, so
I think “patch needed” or “patch review”
Le 17/01/2011 23:41, Nick Coghlan a écrit :
> On Tue, Jan 18, 2011 at 6:54 AM, Antoine Pitrou wrote:
>> [...]
>> Also, I see no need to put the maintainers list in the dev guide,
>> actually.
>
> Every time I see someone syncing the version-independent maintainers
> list across branches a little
> Right now, the tests for the unittest package are under the
> package directory instead of Lib/test where we have most of the
> other tests.
>
> There are some other packages that do the same thing, each for
> their own reason.
The corresponding bug report is #10572 (opened by Michael Foord).
Hello
See http://bugs.python.org/issue3561 (rejected by Martin).
Regards
___
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-
Le 19/01/2011 18:04, Georg Brandl a écrit :
> Am 19.01.2011 16:25, schrieb Eric Smith:
>>> Bonus question: if we remove maintainers.rst from py3k, what do we do in
>>> 3.1 and 2.7? I’d favor removing them over keeping outdated versions.
>>
>> Is there not some advantage to knowing who was the main
Hello,
> --- python/branches/release31-maint/Lib/configparser.py (original)
> +++ python/branches/release31-maint/Lib/configparser.py Wed Feb 2
> 22:35:48 2011
> @@ -88,7 +88,7 @@
> """
>
> try:
> -from collections import OrderedDict as _default_dict
> +from collections i
Thanks Nick, I moved the entries.
Cheers
___
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
>> +How do I compare my working copy to a remote repository?
>
> To save anyone else pointing this out, I'm now aware that "hg
> incoming" and "hg outgoing" are the actual commands I want.
incoming and outgoing compare your repository to a remote repository,
not your working copy.
Regards
__
Le 06/02/2011 17:15, Antoine Pitrou a écrit :
> On Sun, 06 Feb 2011 02:10:15 +0100
> brett.cannon wrote:
>> To create your patch, you should generate a unified diff from your
>> checkout's
>> top-level directory::
>>
>> -svn diff > patch.diff
>> +hg outgoing --path > patch.diff
>
> S
Le 09/02/2011 23:49, Brett Cannon a écrit :
> On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote:
>>> -To get a read-only checkout of CPython's source, you need to checkout the
>>> source
>>> -code. To get a read-only checkout of
>>> +To get a read-only checkout of CPython's source, you need a wo
Hello,
Thanks for wanting to contribute and welcome to python-dev :)
Ideas are usually discussed first on python-ideas to assess usefulness,
get the pulse of the community, beat the API into shape and such things
before coming up to python-dev. (A number of core devs are on both lists.)
You may
> antoine.pitrou pushed f22bac464e11 to devguide:
> summary:
> Comment out the "make patchcheck" advice, since it doesn't work for a
> non-SVN workflow.
patchcheck should work after
http://svn.python.org/view?view=rev&revision=85767 (from
http://bugs.python.org/issue8999). What specific part of
Hi,
I’ve wanted to move our TODO wiki page to the bug tracker for months,
thanks for doing it! Auto-nosy is useful to catch new bugs; for
existing bugs, instead of adding yourself manually to each one and
trigger not-so-useful email, a tracker admin could add you
automatically. I’ve asked on
htt
> Well, it's no good to keep using CVCS terms and mislead users. That the
> "checkout" is not a checkout but a full repository is about the most important
> fact about a hg (or any DVCS) clone.
Well, to really use the Mercurial terms, what you have when you get
stuff from a remote server to your
> import sqlite3
> sqlite3.version
>> '2.6.0'
> sqlite3.sqlite_version
>> '3.7.4'
>
> That's not intuitive. It is better to point sqlite3.version to the
> actual version of sqlite3 used.
We can’t break compatibility for such a small thing. However, it should
be documented in
http://d
Hi,
Le 25/02/2011 20:43, Barry Warsaw a écrit :
> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
> [snip]
>> Note that each of these branch clones will initially have your local
>> master repo as the default path [3,4]. If you'd like to have the default
>> push/pull path to point to ssh://h
Hi,
> Author: raymond.hettinger
> New Revision: 88526
> Log: Add tests for the collections helper class and sync-up with py3k branch.
> Modified: python/branches/release32-maint/Lib/collections.py
> +def new_child(self):# like Django's
> Context.push()
> +'New
> collections._ChainMap itself is private, so changes can be made to its
> API even in a maintenance branch.
Makes perfect sense, thanks for the reply :)
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
Le 26/02/2011 17:44, Antoine Pitrou a écrit :
>> Can we just get rid of "trunk" altogether? It's history is a strict
>> subset of the 2.7 branch's history, isn't it?
>
> Named branches are exclusive, they can't be a subset of each other ;)
Can we just use default for trunk and py3k? For the tim
>> Can we just use default for trunk and py3k? For the time when both
>> trunk and py3k were active, it would create two unnamed branches on the
>> default branch, but one merge would solve that.
>
> IMO, a dummy merge at the tip of the default branch may confuse users
> looking at the history, e
>> Named branches are exclusive, they can't be a subset of each other ;)
Actually, they can. Take the example of the Mercurial repo itself. They
fix bugs in the stable branch and add features in default. When they
merge stable into default and commit, default becomes a superset of
stable. That
> +if branch in ('trunk', 'legacy-trunk',
> + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'):
Wouldn’t using a whitelist instead of a blacklist protect against new
named branches too?
___
Python-Dev mailing list
Python-Dev@python.
Hi,
> shelve
> http://mercurial.selenic.com/wiki/ShelveExtension
> Store un commited changes away so they dont affect generation
> of the patch
I never use it.
>transplant
> http://mercurial.selenic.com/wiki/TransplantExtension
> required to port patches be
> Then we will have to fix the hook each time we want to add a new
> legitimate branch.
The alternative is to edit the hook each time we want to remove a former
legitimate branch, plus have another hook to refuse new named branches.
> I have no preference really.
Looks like a ±0 to me :)
Regards
> Never use them. Clones are okay.
s/use/used/
___
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
> It's not a matter of dependence on iteration order, but of
> reproducibility (in my case there were minor numerical differences due
> to different iteration orders).
Can you give a code example? I don’t understand your case.
Regards
___
Python-Dev ma
> I've just tried bookmarks and I find them very cumbersome compared to
> named branches (which, unfortunately, can't remain local). I wonder
> what guided their design.
Mimicking git branches.
> (the core issue being that a bookmark blindly follows every commit you
> do, while you would need it
Le 27/02/2011 16:21, Antoine Pitrou a écrit :
>> summary:
>> patchcheck does work
> How does it find out which changesets it should operate on?
It operates on changed files, just like with Subversion:
http://hg.python.org/cpython/file/tip/Tools/scripts/patchcheck.py#l40
→ hg status --added --mod
Le 27/02/2011 16:22, Antoine Pitrou a écrit :
>> - Remove one XXX that was in a warning block, not a comment
> Well, this is a XXX because that means we could find something else to
> advocate, not because the reader must take it as a warning.
My point was that that should be either a comment with
> I really meant superfetatory
Those damn French people with their foreign words.
___
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
> Remember there's no tone of voice, facial expressions or body language
> on the internet
This linguist approves.
> smileys are your friend when kidding around :)
All French core developers know I’m French too, but other people on this
list could have mistaken me, you’re right.
Cheers
__
> user:Antoine Pitrou
> date:Tue Mar 01 20:51:42 2011 +0100
> summary:
> Update instructions to use the new "server-side clone" button
That’s seriously awesome.
Where can we have a look at the implementation?
A remark: Having all clones created under a dedicated namespace (say
Hi,
> Author: victor.stinner
> Date: Wed Mar 2 02:03:14 2011
> New Revision: 88709
> Log: Issue #8923: cache str.encode() result
>
> When a string is encoded to UTF-8 in strict mode, the result is cached into
> the
> object. Examples: str.encode(), str.encode('utf-8'), PyUnicode_AsUTF8String()
> For non-Windows, get people to run "make patchcheck".
The non-non-Windows equivalent should be something like “./python.exe
Tools/scripts/patchcheck.py” (I don’t remember if the leading ./ is
required).
FTR, what the make target is a bit more complicated:
“$(RUNSHARED) ./$(BUILDPYTHON) $(srcdir)
Hi,
> Roadmap is not a strict plan for release. It helps people
> *self-organize into teams* around specific feature or bugs.
I think the tracker is used to this effect with success.
> Yes, there can (or even should) be a way for everybody with Python
> account to vote on items in the Roadmap
Doi
Hello,
> changeset: 68315:b9d76846bb1c
> branch: 2.6
> parent: 68264:50166a4bcfc6
> user:Vinay Sajip
> date:Mon Mar 07 15:02:11 2011 +
> summary:
> Issue #11424: Fix bug in determining child loggers.
This does not look like a security bug, and is therefore not s
Hi,
Le 08/03/2011 19:04, Daniel Stutzbach a écrit :
>>> With a branch you can easily view the full patch, making a branch
>>> strictly more general.
>> I just asked this before: how *exactly* do you do that?
> I confess: I'm not sure exactly how to do it in hg. I know it's easy in
> git; I assume
Hi,
First, thank you for stepping up again to work on the code review
integration.
> It seems that the dev guide recommends to use the --git option in hg
> diff.
From “hg help diffs”:
While this standard format [unified diff] is often enough, it does
not encode the following information
Hi,
>> changeset: 68315:b9d76846bb1c
>> branch: 2.6
>> parent: 68264:50166a4bcfc6
>> user:Vinay Sajip
>> date:Mon Mar 07 15:02:11 2011 +
>> summary:
>> Issue #11424: Fix bug in determining child loggers.
>
> This does not look like a security bug, and is therefo
> The idea is to pull their remote branch but not merge it, which will create
> multiple heads locally.
“hg pull some-repo-uri” does that.
> Then find the common ancestor of my regular local head and the new head,
> and diff the ancestor with the new head.
I think Mercurial revsets can do that, bu
Hi,
> From what I understand, we're supposed to forward-port in Mercurial,
Correct, but only in maintained branches, not security-mode branches.
> which is why I started with 2.6 (the bugfix wasn't applicable to 2.5).
As I said in my first message:
>>> This does not look like a security bug, and
> I have a deprecation warning that I need to make an error in 3.4.
A neat trick to remember to do those changes is using a test that fails
if something does not raise a DeprecationWarning if sys.version_info[:2]
== (3, 3), or an error if sys.version_info[:3] == (3, 4). You write
those tests once
Hi,
> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:
Thanks for doing that!
About this bit from the VM meeting notes:
- original Python-on-Parrot ran into problems due to semantic
mismatches between Perl 6 and Python - reached the
> hg revert -ar default
You can’t combine the -r option with other options. (Yes, it’s a known
bug.)
On an unrelated note, you can use “-r .” to tell Mercurial to find the
branch name from the working directory instead of having to remember and
retype it.
Regards
___
>> You can’t combine the -r option with other options. (Yes, it’s a known
>> bug.)
> Are you sure? It just worked here: [...]
> (perhaps you're thinking of -R instead?)
Exactly.
>> On an unrelated note, you can use “-r .” to tell Mercurial to find the
>> branch name from the working directory in
tl;dr: +1 for pushing only clean changesets.
Le 13/03/2011 14:44, Antoine Pitrou a écrit :
> I think we (python-dev) will need to take a decision on this.
>
> My personal opinion is that we don't want to see all intermediate
> commits which led to a patch (or feature) in the main repo. It may
> a
> No, probably we should add some sort of __yes_i_am_public__ override
> attribute that pydoc looks for. It's such a pity that those methods
> have to have underscores...
My opinion is that pydoc should use __dir__ (namedtuple does not
currently use it but could).
Regards
Hello
Will it be okay to make you nosy on a bug report to ask for an expert
opinion when the current developers need it? If yes, I’ll mark your
name as “retired” in the experts file, if not I’ll remove it.
Thanks for your contributions, and have fun in your next adventures!
[Alexander]
> Unfort
> The short summary is that the Parrot VM is a very good semantic fit for
> Python (AFAICT, a better fit than it is for Perl 6, though I haven't
> done the feature-by-feature comparison).
Thanks for the write-up. The point quoted above is especially useful,
since I vaguely remembered reading th
> I do distinctly recall __version__ being standardized for other
> purposes too, but I have no idea how to find that reference... It
> probably was well before 2000.
Maybe you were thinking about Pydoc, which will display __version__ in a
dedicated section of the doc.
Regards
___
> I have been avoiding hg import because my understanding is that it
> defaults to commit, and I don't see that it has any advantage over patch
> itself.
“hg import” understands the extended diff format, which patch does not.
(That format has been described a number of times already, see
http://me
Le 20/03/2011 02:59, Ned Deily a écrit :
> On a Unix-y system, here is one way to do it (no warranty on the
> installation instructions!):
With all due respect, the instructions are overly complicated, and may
also run afoul of the system conventions (sudo will put files in
directories that shoul
Le 22/03/2011 00:46, Greg Ewing a écrit :
> Ben Finney wrote:
>> That seems to me the ideal: preserve all revision history for those
>> cases when some user will care about it, but *present* history cleanly
>> by default.
>
> Seems to me the basic problem here is the way Mercurial
> presents you w
Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
> I've added a feature in the bug tracker where submitters can post
> Mercurial repository URLs, and then repeatedly create patches. Roundup
> will extract the current patch (cpython-default:submitter-default),
> and attach the patch to the issue (
> I still don't understand what that's supposed to look like. Is it supposed
> to be a URL which refers to my local repository?
No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting service).
You have to use one public re
101 - 200 of 411 matches
Mail list logo
