Hello,
Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
> 16.09.17 12:39, Larry Hastings пише:
>> So why don't decorators allow arbitrary expressions? [...]
>
> Actually I remember somebody raised this question a year or two ago,> but
> don't remember details.
The discussion I remember wa
Le 18/03/2014 04:05, Jeff Allen a écrit :
I found it helpful to practice extensively on something that doesn't
matter. The gap for me is still examples of what I want "done well".
Clearly the Python repos represent complex work, but even accepting it
is all done well, are without much commentary.
Hello,
Le 01/04/2013 16:51, Grigory Petrov a écrit :
> But what python code is responsible for creation of this bootstrapper
> executables? I have searched python 2.7.3 source code for some time, but
> can't find a place.
Setuptools is not in the standard library, so you would need to search
the
Hi,
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
> >>> @fun.register(int)
> ... def _(arg, verbose=False):
> ... if verbose:
> ... print("Strength in numbers, eh?", end=" ")
>
Le 23/05/2013 16:10, Łukasz Langa a écrit :
>> Does this work if the implementation function is called like the first
>> decorated function?
> No, the ``register()`` attribute returns the undecorated function which
> enables decorator stacking, as well as creating unit tests for each
> variant inde
Le 17/06/2013 20:49, Benjamin Peterson a écrit :
> Reading Python coding cookies is outside the purview of TextIOWrapper.
> However, it would be good to have a function in the stdlib to read a
> python source file to Unicode; I've definitely implemented that
> several times.
IIUC you want http://d
Le 21/08/2013 14:22, Tim Peters a écrit :
> BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't
> currently exist in the 3.3 or default .hgtags files. So long as 3.2
> has a topological head, people on the 3.3 and default branches won't
> notice (unless they look directly at .hgtags
Hi,
Le 01/02/2022 à 07:25, Martin Dengler a écrit :
The fact people are assuming bad faith and spilling ink about those getting
involved with that extremely-underserved part when contributors are sorely >
needed is counter-productive.
I disagree, the original message was a good-faith ques
Le 2020-07-02 à 09 h 52, Paul Moore a écrit :
> What *is* the correct inclusive way to refer to an unidentified person
> in a technical document, without sacrificing clarity by using
> convoluted circumlocutions like "he/her/they" or over-use of the
> passive voice?
One technique is alternating ge
Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
> Other possible approaches:
> * Extend the distutils API so that the .so file extension can be passed in,
>instead of being essentially hardcoded to what Python's Makefile contains.
Third-party code rely on Distutils internal quirks, so it’
Le 24/06/2010 19:48, Brett Cannon a écrit :
> P.S.: I wish we could drop use of the 'module.so' variant at the same
> time, for consistency sake and to cut out a stat call, but I know that
> is asking too much.
At least, looking for spam/__init__module.so could be avoided. It seems
to me that the
Your plan seems good. Adding keyword arguments should not create
compatibility issues, and I suspect the impact on the code of build_ext
may be actually quite small. I’ll try to review your patch even though I
don’t know C or compiler oddities, but Tarek will have the best insight
and the final wor
[Barry Warsaw]
> As an aside, I wonder if it would make sense to create an Ubuntu/Debian
> package that essentially just depended on all those -dev packages. That way
> you could install this python-uber-dev package and get everything you needed
> to build a sumo Python.
I don’t know. Any Debian
The workflow described by Brett looks like a patch-and-email one. It’s
used by the Mercurial team itself, and has the advantage of not
cluttering the history with lots of changes, since you only apply one
patch in the end. However, in the not-so-long run I feel that a simpler
and more mercurialic w
hg.python.org/cpython is a test setup for people working on the
transition. It is not guaranteed to be usable, it usually lags, and it
will be rewritten before the real switch IIRC.
code.python.org/hg is a mirror kept in sync for use by contributors who
don’t want to use Subversion now.
After the
Hello Anatoly
I’m thankful that you give time and energy to the issues raised by the
migration. As a minor contributor, I’m eager for the migration, and I
also find healthy that there is discussion about these things. However,
I think that there is too much discussion right now. I offer some facts
> Éric, you letter is discouraging.
That’s the right term. I wanted to discourage you from fruitless endeavors.
> This is not for coredevs, who already "decided" - it for the rest of
> the world.
I don’t think there is a discrepancy between the core devs that want to
keep the power and do what the
> 2, throwing away local changes is not that easy in Mercurial,
>if you have committed them already. There are extensions to
>uncommit, but they are discouraged and have limitations. So it's
>best to throw away everything and start over fresh, which is
>faster if you have a pristine
>> That tutorial is not ~100 pages. It's actually a good tutorial.
> That's why I posted it here, but it still >80 pages in my browser.
Perhaps you meant 80 screens, or a different tutorial. hginit is a short
tutorial useful for Subversion users who don’t have the time to read the
hgbook.
Regards
> But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
The other risk with history-editing extensions is that they use the
merge and rebase machinery to do their work, so they require a clean
working directory. Otherwise you may loose uncommitted changes.
Not requiring any Mercurial extension to contribute to Python would be a
nice policy to lower the
>> Not requiring any Mercurial extension to contribute to Python would be a
>> nice policy to lower the entry bar.
>
> That is already defeated by the need for the eol extension (which is now
> built-in in hg 1.6). Activating mq is something every developer should
> manage...
Okay, make that “no
Not requiring any Mercurial extension to contribute to Python would be a
nice policy to lower the entry bar.
>>>
>>> That is already defeated by the need for the eol extension (which is now
>>> built-in in hg 1.6). Activating mq is something every developer should
>>> manage...
>>
>> Oka
> I'm not sure if I misunderstand Martin's intent, but in principle, if you
> want to merge one changes (not changesets!) branch into another, all you
> need to do would be "hg merge ". Subsequently committing
> the merge (after fixing conflicts) creates a new changeset "on" the current
> branch.
[Martin Geisler]
> You basically need to replay the changes -- the transplant extension can
> do this for you. This is more or less a wrapper around 'hg export'
> (gives you a diff) and 'hg import' (applies the diff).
Core developers seem to be okay with svnmerge, so perhaps a
familiar-looking com
Hello pydev
I’d like to volunteer to maintain a tool but I’m not sure where I can
help. I’m already proposing changes to Brett for
Tools/scripts/patchcheck.py, and I have commented on Tools/i18n bugs,
but these ones are already maintained by their authors (e.g. Barry is
assigned pygettext bugs) an
>> Because it's not a transition. It's a mirror. It was put in place
>> before the hg migration plan was accepted, IIRC.
> Where is this migration plan then if it is not in PEP?
The “hg migration plan” is PEP 385. It means moving from svn.python.org
to hg.python.org.
It is not possible to make co
> I promised to write a PEP about that some time in the future. (Probably after
> 3.2 final.)
Nice.
It seems that projects putting Sphinxy reST in their doc are using
automatic doc generation. This is however not always the best way to
make good doc, as demonstrated by Python’s hand-written,
ver
> I was actually going to suggest something along those lines post
> transition, since Hg will have an email address for everyone - leave
> push notifications coming from the bot (so existing filters based on
> the bot address keep working), but include the push author in the
> reply-to field.
IIR
[Nick]
>[me]
>> IIRC, you can’t know who pushed without kludgy hackery.
>
> [...] Note that the current distutils2 emails to python-checkins
> already say "Tarek Ziade pushed..."
I looked at mail.py in the hooks repository and learned that hooks get
an HGPUSHER variable in their environment. Nice
> The "--help" option appears as a hyperlink leading to
> http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which is
> hardly relevant or useful. [...]
>
> -h/:option:`--help`
>print a short usage message and exit
I think this is a doc bug in Doc/documenting/markup.rst
:cmdo
Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the
Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the
Le 18/07/2010 23:17, Alexander Belopolsky a écrit :
> On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence
> wrote:
>> Maybe going off on a tangent, but I find it frustrating because you (plural)
>> can't find a given module on the issue tracker. Say I'm looking for issues
>> relating to smtplib, all
> Sorry to add the third way to the mix, but shouldn't the recommended
> way to run a module as a script be python -m modname? As in
>
> $ python -m test.regrtest test_spam
This is true but orthogonal to our problem, which is that
:program:`python -m thing` is wrong if I understood the doc right
> Using "setattr" to set attributes, where the attribute string
> comes from an external source, can create a security hole. Remember
> that you can override functions on an object, for that object only,
> by setting an attribute. This offers the opportunity for an attack
> similar to SQL in
> Using "setattr" to set attributes, where the attribute string
> comes from an external source, can create a security hole. Remember
> that you can override functions on an object, for that object only,
> by setting an attribute. This offers the opportunity for an attack
> similar to SQL in
Le 30/07/2010 17:04, Michael Foord a écrit :
> There is no type checking or interface requirements in my plugin
> proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configuration loading, plugin registration/activation, s
> It has an API, but the plugins are not interface based (so interface
> requirements don't need to be part of the plugin system).
Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces in my head :) Also, the I in API does mean
interface, but not imply b
>> Note that the PEP 376 implementation is mainly done in pkgutil. A
>> custom version lives in distutils2 but
>> when ready, will be pushed independently in pkgutil
>
> Ok. It would be helpful for unittest2 (the backport) if it was *still*
> available in distutils2 even after the merge into pkgu
Good call.
Alternative idea: Have a new status “unread” to make searching easier
for bug people. Or a predefined custom search for nosy_count == 1.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
> Perhaps just another number to track in the weekly bug summary?
*puts bug person hat on* I made the same suggestion to Ezio, so +1
I’ve just created a public query named “Reports without replies”, you
should be able to add it to your queries list, or a tracker admin could
decide to add it to th
> Speaking of which... Your documentation says it's named ~/unittest.cfg,
> could you make this a file in the user base (that is, the prefix where
> 'setup.py install --user' will install files)?
Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory
> The PLUGINS file can be kept only for the state value, which is not read-only.
It will be for OS packages.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
Le 02/08/2010 14:31, exar...@twistedmatrix.com a écrit :
> On 12:21 pm, m...@egenix.com wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defin
> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.
AFAICT, Ezio certainly wants to solve the status/stage/resolution
unclear overlap, and in gen
> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
>
> Type: Plugin for MyCoolApp
>
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation
Hello
> hmm... BARRY_AS_BDFL and barry_as_FLUFL
Oh, bad consistency. Should have been BARRY_AS_FLUFL and barry_as_flufl.
from __future__ import barry_as_FLUFL
> nothing noticable happened.
I made some tests about that and found that the behavior didn’t match
the PEP; I have to redo experi
Hello
Le 03/08/2010 13:09, Michael Foord a écrit :
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
> [idea about sqlite3 db for caching]
[distros won’t like it, the filesystem is the db]
>>> [the db is a cache, it does no
> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functoo
Hello list
Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that
evolved into a discussion about the proper location to use for config files.
Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a
config file too.
It would be nice to define one standard location
> I'd like to see a more complete proposal, including:
Fair enough.
tl;dr: Locating config files is hard.
I have looked at http://github.com/ActiveState/appdirs (MIT) for
OS-specific bits of knowledge. (Note that the directories it uses for
free OSes are not compliant with the freedesktop.org Bas
> PEP 370 already specifies a directory for Python config files:
>
>> user data directory
>>
>> Usually the parent directory of the user site directory.
>> It's meant for Python version specific data like config
>> files, docs, images and translations.
Thanks for pointing that. Howeve
>> If the files are shared among all users then /usr/local/
>> seems more reasonable.
Oh, right, I forgot to think about system-wide config files. They have
to be supported by another function in site.
A lot of programs have similar-looking code to get a list of filenames
and then process it with
Le 12/08/2010 12:18, Steve Holden a écrit :
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location?
As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory
for user site-packages is not the right place to put config
> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.
Rest assured that I don’t
> A good alternative would be to make the config file overridable. That way
> you can have sysconfig.cfg next to sysconfig.py or in a known config
> directory relative to the python stdlib install but also let the
> distributions and individual sites override the defaults by making changes
> to /e
Thanks for the replies.
The dev FAQ is clear about regular use, it tells about the
svnmerge-commit-message too, and people in #python-dev have told me that
the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
committed r84190 in 3.1 manually, but it should have been an svnmerge of
Thanks Eric for the reply and Nick for mentioning --record-only, this
was what I needed.
Tarek: I find the bug tracker simpler than svnmerge to keep track of
merges to be done. Of course, when there is no report, as for the typo
fixes I made, this doesn’t help. Oh well.
I’m going to do some Mercu
> The question really is whether there is any chance that they will get
> released, in some form. There won't be further binary releases (at least
> not from python.org), so there definitely won't be a CHM release.
I think that the most important release is docs.python.org/2.6,
regardless of pytho
Hi Sylvain
> Sorry for errors in the e-mail and the patch, but i'm french student
Being polite or cautious is a good thing in Internet communication, but
you don’t have to apologize about that. Everyone tries to express
themselves as clearly as possible, but nobody is judged because of
language.
Thanks everyone for the feedback. I think my question has got good
answers (usage patterns, versionchanged/versionadded, lack of releases,
opinion of the doc editor), so it seems good for our users and for
developers to let the 2.6 docs in peace.
Regards, and a toast to 2.6.6!
> It just occurred to me that it could be interpreted as a breach of the
> moratorium. On the other hand, according to PEP 3003:
>
> “The case for adding a method to a built-in object can be made.”
>
> This case seems even lighter than adding a new method.
I’ve been satisfied to see other pr
> What about adding an intermediate namespace called "cache", so that the new
> operations are available like this:
>
> print get_phone_number.cache.hits
> get_phone_number.cache.clear()
>
> ?
>
> It's just a little more overhead, but I think it reads quite a bit better.
Or we could
> Sure I will look into this. Could you please point me towards the
> repository(I'd love it if I could use mercurial for the development process
> rather than svn)?.
Core developers still use Subversion (we’re in the process of
switching), but you can clone the mirror at
http://code.python.org/hg
> Yeah, I changed my mind and have now documented it properly. The 3.2
> versionadded tag on show_code is currently a little questionable
> though. Guido actually checked in the original (undocumented) version
> of show_code before 3.0 was released. The only thing new about it in
> 3.2 is it being
Author: georg.brandl
Date: Wed Sep 8 12:43:45 2010
New Revision: 84619
Log:
Add Lukasz.
I guess you had to asciify Łukasz’ name because developers.txt is in
Latin-1, which cannot encode the first character. I think the file
should be recoded to UTF-8 so that we have no artificial restrictions o
> I would agree, but also suggest a latin transcription for
> non-latin-alphabet names.
I think that people whose alphabet is for example Cyrillic already use a
Latin transliteration in those files, so it’s good. Are you also
including names using extended Latin alphabets (like Łukasz) in your
s
>> I think that people whose alphabet is for example Cyrillic already use a
>> Latin transliteration in those files, so it’s good.
> At present, such people have no choice ;-).
Right :) So the new policy of real name thanks to UTF-8 + ASCII
transliteration is a superset of the existing conditions
+zlib
+
+
+The :mod:`zlib` extension is built using an included copy of the zlib
+sources unless the zlib version found on the system is too old to be
+used for the build::
Unless or if? Building with an included copy *if* the system one is too
old makes sense to me, not the contrary. Am I n
Le 15/09/2010 21:45, Tarek Ziadé a écrit :
> Could we remove in any case the wsgiref.egg-info file ? Since we've
> been working on a new format for that (PEP 376), that should be
> starting to get used in the coming years, it'll be a bit of a
> non-sense to have that metadata file in the sdtlib shi
> * add a decorator to wsgiref that supports using native strings as
> output instead of bytes, for ease-of-porting (combine mod_wsgi's
> ease-of-porting w/"flat"'s simple verifiability)
Ah, thanks, I’ve been reading web-sig and was totally at a loss to
understand what a “native string” was. No
Le 15/09/2010 21:45, Tarek Ziadé a écrit :
> Could we remove in any case the wsgiref.egg-info file ? Since we've
> been working on a new format for that (PEP 376), that should be
> starting to get used in the coming years, it'll be a bit of a
> non-sense to have that metadata file in the sdtlib shi
> If you're talking about distutils2 on Python 3, then of course
> anything goes: backward compatibility isn't an issue. For 2.x, not
> writing the files would indeed produce backward compatibility problems.
I was talking about distutils in 3.2 (or in the release where
wsgiref.egg-info goes awa
Hello
+ NOTE: If you are thinking of defining your own levels, please see
the section
+ on :ref:`custom-levels`.
I think those instances of upper-case-as-markup should either be real
reST note/warning/etc. directives or plain English (that is, integrating
“NOTE:” into the text flow, for examp
>+@unittest.skipIf(sys.platform.startswith('win'),
>+"This test is only appropriate for POSIX-like
systems.")
Is win32 the only non-POSIX supported platform now that OS 9 support is
gone? I find those values in the docs for sys.platform: win32, cygwin,
darwin, os2, os2
> Log:
> Remove references to read() and write() methods, which are useless
> synonyms of recv() and send()
Unless I’m mistaken, ssl.SSLSocket.write is still useful for use with
print, pprint and maybe other functions, so I think the method should be
listed somewhere.
Regards
___
Le 23/09/2010 19:22, Terry Reedy a écrit :
> As of just now, if you were to wonder "What (security) bugs are open for
> 2.5" and search on open 2.5 issues, you would get a list of 44 issues.
> It is only 44 instead of hundreds because of the work I and Mark have
> done in the last 4 months. It i
How about revamping the type/versions fields?
Issue type
() Feature request (blocked by moratorium: () yes () no)
() Bug (found in: [] 2.7 [] 3.1 [] py3k)
() Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)
I’m getting tired of explaining the meaning of the versions field again
and ag
Hello
Le 25/09/2010 10:20, anatoly techtonik a écrit :
> On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan wrote:
>> That's a good point actually... why *isn't* there a pydotorg-wiki-sig?
>> (Aside from the obvious point of nobody ever asking for one).
>
> Because Yet Another Mailing List doesn't so
Le 23/09/2010 22:51, Éric Araujo a écrit :
> Le 23/09/2010 19:22, Terry Reedy a écrit :
>> As of just now, if you were to wonder "What (security) bugs are open for
>> 2.5" and search on open 2.5 issues, you would get a list of 44 issues.
>> [...] It it 44 ins
> If they were actively discouraged, perhaps performing a relative
> import would raise a warning,
This would be done if this import style was deprecated. It’s different
from it being discouraged.
> or maybe distutils would raise a warning at install time,
Distutils does not inspect source files.
Le 08/10/2010 17:31, Jon Ribbens a écrit :
> I'd just like to say "pypackage" again.
In the Python world, a package is a directory with an __init__.py file.
Distutils and distutils2 try to avoid confusion and call the other
things “distributions”.
Of course, everyone outside of the Python world
Le 12/10/2010 01:11, Giampaolo Rodolà a écrit :
> Wouldn't be kinda weird that one can open the command prompt and run
> "pysetup" but not "python" on Windows?
> I recall an old issue on the bug tracker in which the latter proposal
> was widely discussed and finally rejected for reasons I can't rem
Hello
[Sorry if this comes twice, connection errors here]
(A bit of context: The original message comes from bug #2775, “Implement
PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.)
> I am very glad you're reorganizing the Standard Library. Thumbs up! I
> hope everything will comply
Hi everyone
[Sorry if this comes twice, connection errors here]
Raymond Hettinger noticed on the tracker that there are different
interpretations of the “accepted” resolution:
> Traditionally it denotes an approved patch, not a agreement that the
> bug is valid.
Daniel Stutzbach and I are (were
Hello
(A bit of context: The original message comes from bug #2775, “Implement
PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.)
> I am very glad you're reorganizing the Standard Library. Thumbs up! I
> hope everything will comply to PEP 8 after you're done.
You may have missed the
Hi everyone
Raymond Hettinger noticed on the tracker that there are different
interpretations of the “accepted” resolution:
> Traditionally it denotes an approved patch, not a agreement that the
> bug is valid.
Daniel Stutzbach and I are (were) two users of the second meaning. It’s
more useful
Congratulations Victor! This is not a small feat. The PSU should send
you cookies to thank you, but they won’t since they don’t exist and
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
+``Filters` can be used by ``Handlers`` and ``Loggers`` for more
↑ missing ` here.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
I remember a discussion about Vim files some time ago. I use Vim with
the files from Misc/Vim, which are up-to-date and more useful than the
files shipped with Vim. I don’t use plugins or external files, so I’m
-1 on removing Misc/Vim.
Regards
___
Pyt
> From: *Boštjan Mejak*
> Since Python 3.2 accepts feature requests, take this fix as a feature
> request. Please forget about preserving the compatibility with old pickles.
You can reopen #7351 as a feature request for 3.2. A serious proposal
has to take compatibility into account, note. It is
Le 28/10/2010 22:52, anatoly techtonik a écrit :
> Can anybody summarize the outcome?
> Is it that renaming BadZipfile to BadZipFile with backward compatible
> alias and deprecation note breaks something?
See #7351 or r85874.
Regards
___
Python-Dev mai
> Author: eric.smith
> Date: Thu Nov 4 18:06:58 2010
> New Revision: 86170
>
> Log:
> Issue #6081: Add str.format_map. str.format_map(mapping) is similar to
> str.format(**mapping), except mapping does not get converted to a dict.
> Modified: python/branches/py3k/Doc/library/stdtypes.rst
>
According to #python-dev, there’s no need to go through
python-checkins/-dev for typos, so I fixed this one in r86247.
Piratical regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
> I'm skeptical that this change should be carried out, then.
Yes, I asked myself the same question. I had done the svnmerge from
py3k, and when I saw that only one change was left, I wondered whether I
should commit or revert.
> It's easy to argue that this can't possibly hurt (but I can certain
>> New Revision: 86276
>> Log:
>> Fix #10252 again (hopefully definitely). Patch by Brian Curtin.
>
> It seems this and previous fixes should be backported to 2.7.
Certainly. I was waiting on buildbot feedback before doing it.
Regards
___
Python-Dev
>> It seems this and previous fixes should be backported to 2.7.
>
> Perhaps there should be a 'backport 2.7' keyword to check on issues that
> might be but have not been.
The “Your issues” list is very helpful and works well for me. This bug
is still open and assigned to me (and opened in my w
> Author: hirokazu.yamamoto
> New Revision: 86300
> Log:
> Issue #6317: Now winsound.PlaySound only accepts unicode with MvL's approval.
>
>
> Modified: python/branches/py3k/Misc/NEWS
> ==
> --- python/branches/py3k/Misc/
[Martin]
>>> It's rather a matter of agreeing when moving forward: IMO, mere style
>>> changes, code cleanup etc shouldn't be applied to the bug fix branches,
>>> as their only purpose is to provide bug fixes for existing users.
>>
>> [Terry]
>> The omission of the deletion from the 5/5 revision wa
1 - 100 of 411 matches
Mail list logo
