lled, the user
gets a chance to associate file extensions with one of the installed Pythons
found on the system).
Off to read the whole thread on python-dev now ...
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
- Original Message -
From: Steve Dower
> I believe are the purpose of those extensions. If "py.exe spam.pyz"
> already works, I don't see any need for a PEP to add the association in
> the installer.
That would be my view, too
remember - he made some
helpful suggestions to improve it) which does a similar job to PEP 441's pyzaa
and provides improved Windows support (some of which might be supplanted by
py.exe support for .pyz/.pyzw, but I have cases where I can't rely on py.e
nd I haven't looked into it yet; I just skimmed the differences, and
didn't see anything major in launcher.c (I compared with the version in the
default branch of cpython).
Regards,
Vinay Sajip
[1] https://bitbucket.org/vinay.sajip/pylauncher
__
- Original Message -
From: Paul Moore
> I'd also appreciate your views on the spin-off thread and PEP 486
> ("Make the Python Launcher aware of virtual environments").
I just thought of something ... as far as I know, we've enabled searching for a
command on the path - since when a v
won't be hit (though if you rely on the
PATH being correctly set, then it will work as expected because the handling
for e.g. /usr/bin/env python searches the PATH).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
https:/
r, by you! See [1] and [2].
Regards,
Vinay Sajip
[1] http://bugs.python.org/issue17903
[2]
https://bitbucket.org/pmoore/pylauncher/commits/87d41c5a8f0fef5ef22f09570903e7aa4c850e96
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
Sorry, my mistake - I should have checked more carefully. Thank you for
pointing me to the commit where they were removed - I'll install a venv with
Sphinx, revert the change and remove those files from my repo.
Regards,
Vinay Sajip
From: Benjamin Pet
(0.7.3) [for pyramid]
download zope.deprecation (4.0.2) [for pyramid]
download pyramid (1.4)
In the above, nothing was actually downloaded except the metadata. It's just
indicating an intuitive ordering for download based on a topological sort of
the dependency graph - for pyramid,
n't think that the distlib docs suffer
inordinately from being on readthedocs.org - for one thing, I've enabled Disqus
comments, allowing feedback on the docs - not that I've had any ;-)
Closer integration should perhaps happen, but not until the projec
ly, distlib runs on Python 2.6, 2.7 and 3.2+, so there shouldn't be any
concerns about support on those older Python versions.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
-
breaker, but it does mean that you can't e.g. use the ast module in the
implementation. This might be a factor if the mini-language ever grows (as it
recently did, adding parentheses).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@p
voids this issue somehow.
One example of a non-system-wide installation is a source build of Python.
PEP 405 venvs created from a source build should work in the same way as venvs
created using an installed Python.
Regards,
Vinay Sajip
___
Python-D
you add a Misc/NEWS entry for the change / bugfix?
Ok, will do.
Regards,
Vinay Sajip
___
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
27;, '__loader__', '__name__', '__package__',
'encode_basestring_ascii', 'make_encoder', 'make_scanner', 'scanstring']
>>> simplejson._speedups.__file__
'/home/vinay/.distlib/dylib-cache/simplejson/_speedups.so'
&g
aise an ImportError? Or ignore
the wheel - seems wrong? Or do something else?)
Regards,
Vinay Sajip
___
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
but I don't
> see a compelling reason for adding complexity here. It's not really an
> important use case.
Well, my post was to elicit some comment about the usefulness of the feature,
so fair enough. It doesn't seem especially complex though,
use pdb can now read the source code from the
> zip.
Well, it's just an experiment, and I was soliciting comments because I'm not as
familiar with the issues as some others are. Distlib is still only at version
0.1.1, and the mount()/unmount() functionality is not set in
itched on only in the presence of e.g. an environment variable
such as PYLAUNCH_SEARCHPATH, or should we just change the default behaviour
now and risk breaking user scripts which may rely on the current behaviour?
Regards,
Vinay Sajip
___
Python-Dev ma
Paul Moore gmail.com> writes:
> PS Vinay - from this post, I assume you're already looking at this
> code? I was considering trying to put together a patch, but I don't want to
> duplicate effort if you're working on it.
I've taken a quick look at it, but I probably won't be able to make any
cha
how to do it... I've created a pull request
> against the pypa version in case that's of use...
Hi Paul,
Sorry I haven't had a chance yet - real life is very busy at the moment. A pull
request against the pypa version is fine, and I will get to it soo
both 3.3 and 3.4, as it's
not a change in core Python APIs.
In the absence of adverse feedback here, I propose to implement approach #2
on both 3.3 and 3.4.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
.cli())"
should do it.
Regards,
Vinay Sajip
___
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
Oleg Broytman phdru.name> writes:
>
> On Mon, Jun 17, 2013 at 06:37:49PM +0000, Vinay Sajip
yahoo.co.uk> wrote:
> > echo off
> > __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())"
>
>I think you want to pass command line arguments:
>
ll available via
http://www.red-dove.com/python_logging.html if anyone needs it. This version
is not actively maintained, but that shouldn't be an issue.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
t multiple Python versions - Django, say -
can take advantage of this by e.g. offering a copy of these handlers in their
own codebase for use when constrained to work with an older Python version.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
In Python 2.5, logging is 1300
SLOC, less than say tarfile, pickletools, pydoc and decimal.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
Brett Cannon python.org> writes:
> Obviously if one of the getopt supporters has a better way of doing
> this then please speak up.
I'm not a getopt supporter per se - I'm +1 for argparse - but Opster provides
some nice syntax sugar on top of getopt, and can be seen here:
http://blogg.ingspree.
n't, etc.
>
I agree - it's just an approach which shows some promise and is worth exploring.
I'm not suggesting jumping in with both feet. But it does show about getopt that
perhaps there's life in the old dog yet ;-)
Regards,
Vinay Sajip
_
only
happens in two locations - LogRecord.getMessage and Formatter.format - so
making the code do either %- or {} formatting would be simple, as long as it
knows which of % and {} to pick.
Does it seems too onerous to expect people to pass an additional "use_format"
keyword argument with
etween % and {}, but a callable can do
anything. That's more flexible, to be sure, but more specialized formatting
requirements are already catered for using e.g. the PercentMessage/BraceMessage
approach.
Regards,
Vinay Sajip
___
Python-Dev mailing l
Barry Warsaw python.org> writes:
>
> This is a very interesting idea.
>
> Note that one of the reasons to /at least/ support {}-strings also is
> that %-strings are simply too error prone in many situations. For
> example, if I decide to support internationalization of log format
> strin
Vinay Sajip yahoo.co.uk> writes:
> #Just typing this in, it's not tested or anything
> class DollarMessage:
> def __init__(self, fmt, *args, **kwargs):
> self.fmt = fmt
> self.args = args
> self.kwargs = kwargs
>
> def
some short name like
> people do with gettext.
>
Yes,
logger.debug(__("The {} is {}", "answer", 42))
isn't ideal but perhaps liveable with. And hopefully with a decent editor, the
paren-butting annoyance will be minimized.
Regards,
Vinay Sajip
arry wanted to use string.Template for
formatting, he's just got to replace the above import with something like
from logging import DollarMessage as __
Another "working title", please note. And while I've shown these classes being
imported from logging, it doesn't make sense to
Paul Moore gmail.com> writes:
> This seems to me to be almost the same as the previous suggestion of
> having a string subclass:
>
> class BraceFormatter(str):
> def __mod__(self, other):
> # Needs more magic here to cope with dict argument
> return self.format(*other)
>
> _
Paul Moore gmail.com> writes:
> 2. The internal implementation of logger.debug needs to preserve
> string subclasses properly
>
> But the benefit is that the approach allows anyone to use brace
> formatting in any API that currently accepts % format (assuming string
> subclasses don't get mangle
don't know what we don't know"
>
> Is this guy in the Python community?
Not sure, but I believe he's a piece of work and not a guy to get on the wrong
side of ;-)
Regards,
Vinay Sajip
___
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
e call arguments. But this will incur memory overhead and some processing
overhead and I'm not sure if it really buys you enough to warrant doing it.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
actly the reason - to defer the formatting until it's needed.
Otherwise you can always format the string yourself,as you say, and pass it as
the single argument in the logging call - logging won't know or care if it was
passed in as a literal, or was computed by %-, {}-, $- or any oth
n attempting to do those things.
Actually, logging calls str() on the object passed as the first argument in a
logging call such as logger.debug(), which can either be a format string or an
arbitrary object whose __str__() returns the format string.
Regard
yet, so we
> shouldn't do anything in a hurry - and anything that does happen should
> be via a PEP so we can flush out more issues.
Yes, we're just "kicking the tires" on the various ideas. There are things still
a bit up in the air such as what happens when pickling and
r that object. The return
value is used to interpolate into the formatted output, and that's all. So
I don't understand what's being precluded and how - please elaborate.
Thanks & regards,
Vinay Sajip
___
Python-Dev mailing
Brett Cannon python.org> writes:
> Why don't we start something in the sandbox and see how far we can
> get. If no one beats me to it I will add the directory some time today
> and we can start hashing out the solution there.
>
I've done a first cut of a converter from %-format to {}-format str
e for a converter in the reverse direction, if
we're encouraging movement in one particular direction.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
Raymond Hettinger rcn.com> writes:
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
>
I've made a start, but I'm not sure how best to handle the '#' and ' '
e finger-pointing at
logging in general.
Regards,
Vinay Sajip
___
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
MRAB mrabarnett.plus.com> writes:
> Interesting that you're using the %-format to translate %-formats to
> {}-formats!
Yes, ironic, isn't it? ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
htt
quot; % 0x1234
'0x001234'
>>> "{0:0>#8x}".format(0x1234)
'000x1234'
>>>
Someone please tell me if there's a better {}-format string which I've missed!
Regards,
Vinay Sajip
___
Python-Dev mai
gh of course there
are ways of fudging it. The obvious conversion doesn't give the same value:
>>> "{0:#o}".format(0x1234)
'0o11064'
I couldn't see a backward-compatibility mode for str.format generating just a
leading "0" for octal alternative
to the Python docs about how to use
alternative formatting systems with logging?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
ng stops people from using Google to search for "foo
> sucks" or "problems using foo" if they want to research what's been
> said about a package.)
Yes, but it's good to have all the feedback in one place, if possible.
Regards,
Vinay Sajip
___
here
needed.
What's the general feeling here about this proposal? All comments and
suggestions will be gratefully received.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
cool ... what's the point about adding the new method
> instead of using `DictConfigurator` directly ?
When you say "the new method", if you mean "configure" - the pattern is so that
a subclass can override __init__ and do additional setup before configure() is
called.
Regard
ly true with a
one-shot configuration, it's at least easier to debug. Things can get pretty
murky from a diagnostic point of view if code can make arbitrary changes to the
logging configuration during application execution, so that's not a good
practice to encourage :-)
Also, providing a
Antoine Pitrou pitrou.net> writes:
>
> Vinay Sajip yahoo.co.uk> writes:
> >
> > >>> "%0#8x" % 0x1234
> > '0x001234'
> > >>> "{0:0>#8x}".format(0x1234)
> > '000x1234'
>
> Apart f
er has an active maintainer and the latter does not, or am I wrong about
that?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
Not sure if this is needed?
> self.config.update(more)
See my response to Paul Rudin's post about incremental configuration.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Glenn Linderman g.nevcal.com> writes:
> But DictConfigurator the name seems misleading... like you are
> configuring how dicts work, rather than how logs work. Maybe with more
> context this is not a problem, but if it is a standalone class, it is
> confusing what it does, by name alone.
Of
;> sys.getdefaultencoding()
'ascii'
>>> sys.getfilesystemencoding()
'mbcs'
>>> locale.getpreferredencoding()
'cp1252'
which suggests to me that the locale.getpreferredencoding() should be the
default. However, as I'm not a Unicode maven, any suggestions would be
0f}, will print
3e+100
for the same value.
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.
Regards,
Vinay Sajip
___
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
y reasonably usable for
programmatic configuration, but this doesn't address e.g. updating
configurations easily without program code changes, or the ability to configure
from say a YAML node, where YAML may be being used for appli
echanism we use to distinguish between
0o and 0 prefixes, as long as it's one most people are happy with :-)
Regards,
Vinay Sajip
___
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
Benjamin Peterson python.org> writes:
> It's also really easy to just write 0{:o} like my translator does.
How does that cope when handed a negative number to format?
>>> "%#0o" % -1234
'-02322'
>>> "
n't be if the application passes a byte
> string), you MAY omit the BOM.
So ISTM that the right thing to do on 2.x would be: if str to be sent, send as
is; if unicode to be sent, encode using utf-8 and send with a BOM. For 3.x, just
encode using utf-8 an
or more information.
>>> import logging
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__getitem_
t's just about what I've actually done: I was just curious about the
difference between py3k and trunk :-)
If __builtins__ is an implementation detail which can't be relied on, should the
py3k code be changed to the try: form? Or shall I
how best to achieve this.
Thanks and regards,
Vinay Sajip
---
PEP: XXX
Title: Dictionary-Based Configuration For Logging
Version: $Revision$
Last-Modified: $Date$
Author: Vinay Sajip
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Oct-2009
Python-Version: 2.7
I just wanted to establish that I wasn't planning on
introducing any logging-related exception classes.
Thanks for the quick response and detailed feedback.
Regards,
Vinay Sajip
___
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
Vinay Sajip yahoo.co.uk> writes:
> Perhaps TypeError, too.
Sorry, brainfade there. I already mentioned TypeError in the original post :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
arguments around in the original form; and so, in the general case, they are not
available to output in a dict describing the current configuration.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Barry Warsaw python.org> writes:
> http://www.python.org/download/releases/2.6.4/
Good news, but just one little nit: the page above appears to link to the NEWS
file for 2.6.4rc1.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Pyth
part from the API to set/get, _loggerClass is only used by
the manager when instantiating a new logger.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
Brett Cannon suggested I send this to python-dev - also, now, done.
Looking forward to the feedback!
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Terry Reedy udel.edu> writes:
>
[snip]
Terry,
Thanks for your helpful comments. I have checked in some changes to the PEP
(r76533) which take into account the comments you made.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Pyth
Dj Gilcrease gmail.com> writes:
>
> I would recommend removing the class keyword and replacing it with the
> () as you have in the custom examples or replacing () with class so it
> is uniform across all config options
[snip]
>
> This just strikes me as odd to have to remember for built in hand
I need to do to get a
pronouncement. I guess the stdlib slot gives an opportunity for people to air
their views and so I'd be grateful if you added it to the agenda.
Thanks & regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
ng is currently hard to
configure will benefit from these changes, so here's the opportunity to pipe up
and improve things.
Thanks & regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
nges into Python,
I plan to work with the Django community to get improved logging support in
Django for 1.3.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
Hi,
When I look at the mailing list archive for python-dev, I see some odd stuff at
the bottom of the page:
http://mail.python.org/pipermail/python-dev/2010-January/thread.html#95232
Anyone know what's happened?
Regards,
Vinay Sajip
___
Pytho
see them on Gmane (for example, the PEP
3146 thread from yesterday).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
Barry Warsaw python.org> writes:
>
> On Jan 22, 2010, at 10:06 AM, Chris McDonough wrote:
>
> >Can you tell us where Uncle Timmy has been and when he'll be back?
>
> He's given up bags of ham for walls of chocolate.
>
In the Mountain View Choc
- Original Message
> From: Guido van Rossum
> To: Jesse Noller
> Cc: Vinay Sajip ; python-dev@python.org
> >> Assuming PEP 391 gets the nod, then after implementing the changes into
> Python, I plan to work with the Django community to get improved logging
>
Florent Xicluna gmail.com> writes:
> I am a semi-regular contributor for Python: I have contributed many patches
> since end of last year, some of them were reviewed by Antoine.
> Lately, he suggested that I should apply for commit rights.
+1
Regards,
mond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
I think that according to the proposal, the above snippet would be OK, but
def f(**kwargs):
kwargs[
e "/usr/lib/python2.6/urllib2.py", line 1287, in ftp_open
raise URLError('ftp error: no host given')
urllib2.URLError:
>>>
Anyone seen this before? Should I file an issue on the tracker? If I've missed
something obvious, sorry for the noise, but please do tell!
Regards,
Vinay Sajip
___
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
/// hurdles :-)
I'll raise an issue on the tracker.
Regards,
Vinay Sajip
___
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
the existing concurrency stuff. I think it's something to consider only
for a big reorg which would break backward compatibility. IMO it would make more
sense to leave this module as a top-level module for now (a sibling to
"threading", "multiprocessing").
Regards,
Vinay Sajip
___
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
oncerns, and that the method can be overridden to use a more secure
implementation (e.g. HMAC-signed pickles).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
If specified, then makePickle would call this
serializer with the LogRecord instance as the only argument, and use the return
value as the serialized form, instead of calling pickle.dumps.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-De
James Yonan openvpn.net> writes:
> I'd like to propose that the Python community standardize on a
> "deferred" object for asynchronous return values
Have a look at PEP 3148:
http://www.python.org/dev/peps/pep-3148/
___
Python-Dev mailing list
Pyth
James Yonan openvpn.net> writes:
>
> I'd like to propose that the Python community standardize on a
> "deferred" object for asynchronous return values, modeled after the
> well-thought-out Twisted Deferred class.
Ummm, sorry, I seem to need new glasses :-( ignore my last post.
Hi all,
I'm planning to make some smallish changes to logging in Python 3.2, please see
http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html
If you're interested, I'd be grateful for any feedback you can give.
Regard
Nick Coghlan gmail.com> writes:
> To further reduce overhead, would it make sense for the signature of
> the QueueListener constructor to be (queue, *handlers)?
Good suggestion - thanks.
Regards,
Vinay
___
Python-Dev mailing list
Python-Dev@pytho
st. Until 3.2 is out, there may be other
small changes: but you can copy the code over from the 3.2 branch in the Python
SVN repository later and it should work fine under Python 2.6 and 2.7.
Of course if you do find any problems (or have any other questions), please let
me know asap :-)
R
Martin v. Löwis v.loewis.de> writes:
>
> I'm still with Guido here: I'd accept PEP 333 as final in the state it
> had last week, give PJE's edits a new PEP number, and accept that as
> final right away also.
>
This sounds like it should make everyone happy - no rewriting of history, and no
pro
r reversion
of this change, I'll publicise to the wider community in a few days.
Regards,
Vinay Sajip
___
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
Nick Coghlan gmail.com> writes:
> Looking at your checkin though, I wonder if it might be worth
> implementing some little formatting style classes to get rid of the
> if/elif chains from the Formatter code. Something like:
Fair comment: I did think about the messiness of that if/elif, but consid
or backwards-incompatible fixes do you
need to add, i.e. things which cannot be catered for by release27-maint? Or is
this just about the *principle* of having a 2.8?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Vinay Sajip yahoo.co.uk> writes:
> need to add, i.e. things which cannot be catered for by release27-maint? Or is
> this just about the *principle* of having a 2.8?
Never mind - I've just picked up the extra posts on this thread, which for some
reason didn't show up in my r
1 - 100 of 437 matches
Mail list logo
