Talin wrote:
> -- An easy way to iterate over key, value pairs in a dict in
> sorted order. Currently you have to get the list of keys,
> sort them, and then lookup each value, OR you have to
> get the list of tuples and call sorted() with a key= arg
> containing a lambda function that extracts th
Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> I don't much like the $"" prefix
>
> This was discussed during the last round of formatting
> wars, and the conclusion was that having $ both
> inside and outside the string would be too visually
> confusing.
>
>> I don't see a good
>> way to marry th
Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Using {} instead of $/${} doesn't seem like a big win.
>
> Perhaps this is where we differ. To me it
> *does* make quite a substantial difference
> to readability -- easily enough to override
> whatever small advantage there might be in
> following what
> But I figured it was something worth throwing out there :)
>
> Cheers,
> Nick.
I'm finding most of this discussion very interesting although the fine
details haven't clicked for me just yet.
This reminds me of Guido's multi-method blog entry a while back. In
both the cases being discuss
Paul Moore wrote:
> On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote:
>> It seems to me that now to get a duck-typed list, not only do you have
>> to implement all of special methods that define "listy-ness," you also
>> have to find the overloaded functions that are specialized for lists,
>
Guido van Rossum wrote:
> On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> You had said there was some question of what kind of objects the type
>> markers should be. I couldn't (and still can't) see any good reason
>> for them to be anything but a way to ensure [to some level] that the
>> arg
Greg Ewing wrote:
> Jim Jewett wrote:
>
>> I also see the value of keyword-only arguments without unlimited
>> positional arguments. Whether it deserves syntax and what that syntax
>> should be (such as * or *None) may need a pronouncement eventually,
>> but it doesn't have to be complex.
>
> M
Giovanni Bajo wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>
>> This *may* relate to None being an object which isn't the same as
>> "not a value". There currently isn't a way (that I know of) to
>> specify a generally null object outsi
Guido van Rossum wrote:
> On 4/21/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Recently I found a case where I wanted to return something that was more
>> literally *nothing* than a None is. So maybe a null symbol of some sort
>> might be useful in other cases as well
Greg Ewing wrote:
> Ron Adam wrote:
>
>> Or just ...
>>
>> def f(a, b, c=?, d=x):
>
> But there's nothing about this that particularly
> suggests that c *must* be specified with a keyword.
> It looks like just another positional arg with a
>
Raymond Hettinger wrote:
> Greg Wilson wrote:
>
>> One of the reasons I'd like native syntax for sets is that I'd like set
>> comprehensions:
>>
>>a = {b for b in c where b > 0}
>>
>>
>>
>>
>
> This is no good. That form could as easily represent a frozenset
> comprehension or dict compre
Raymond Hettinger wrote:
> [pep-3100 checkin]
>> {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary comprehensions (as
> they would aspire to have an identical notation).
>
>
>
>> There's no frozenset literal; they are t
Guido van Rossum wrote:
> On 4/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I think it's been suggested before that there should be a PY2.x to PY3.x
>> conversion utility to facilitate the move to PY3K. So maybe a sticking
>> point as when to *not* do something w
Jim Jewett wrote:
> On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
>> - introduce '@' as a prefix operator meaning 'freeze'.
>
> I mostly like the concept, but not the operator. Using @ limits it to
> syntax-created literals (because of ambiguity with decorators). Since
> numbers are already
Brett Cannon wrote:
> So, to start this discussion, here are my ideas...
>
> First, the modules must have been in the wild and used by the
> community. This has worked well so far by making sure the code is
> stable and that the API is good.
Those modules and packages that necessary parts of
Raymond Hettinger wrote:
> I'm curious as to whether people will find one-type-with-two-purposes
> easier to learn that what we have now. My experience so far is that
> sets have a near zero learning curve as they are currently implemented.
And it's not just about ease of learning to use, b
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Would it be worthwhile to design a common rounding mechanism that can be
>> used
>> to cleanly round values to the built in floating point type, as well as
>> being
>> able to access the different rounding modes for decimal instances?
>
> Sounds li
Greg Ewing wrote:
> Ron Adam wrote:
>
>> I'm still not sure why "__round__" should be preferred in place of
>> "round" as a method name. There isn't an operator associated to
>> rounding so wouldn't the method name not have unders
Nick Coghlan wrote:
[Clipped other good points.]
> 3. The question has been raised as to whether or not there is a practical way
> for a developer to use annotations that make sense to a *static* analysis
> tool
> that doesn't actually execute the Python code
>
> If someone figures out a way
Paul Prescod wrote:
> On 8/19/06, *Ron Adam* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> @callmeta
> def foo( a: [ SetDoc("frobination count"), InRange(3,9) ],
> b: InSet([4,8,12]) )
>
Paul Prescod wrote:
> On 8/19/06, *Ron Adam* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> The callmeta decorator wouldn't provide any extra information itself,
> all it does is decorate(wrap) the functions so that the meta data gets
>
Paul Prescod wrote:
> I guess I still don't really understand what he's getting at or what the
> value of @callmeta is in that example. It just seems like extra noise
> with no value to me...
>
> Ron: what *precisely* does the @callmeta decorator do? If you can
> express it in code, so much th
Nick Coghlan wrote:
> Fredrik Lundh wrote:
>> Nick Coghlan wrote:
>>
Nick Coghlan wrote:
> With a variety of "view types", that work like the corresponding builtin
> type,
> but reference the original data structure instead of creating copies
support for string views wou
Jim Jewett wrote:
> The end result is that even if I find a solution that works, I think
> it will be common (and bug-prone) enough that it really ought to be in
> the language, or at least the standard library -- as it is today for
> objects that don't go out of their way to prevent it.
The usua
Nick Coghlan wrote:
> Ron Adam wrote:
>> Nick Coghlan wrote:
[clipped]
>> It might be nice if slice objects could be used in more ways in python.
>> That may work in most cases where you would want a string view.
>
> That's quite an interesting idea. With that
Nick Coghlan wrote:
> This idea is inspired by the find/rfind string discussion (particularly a
> couple of comments from Jim and Ron), but I think the applicability may prove
> to be wider than just string methods (e.g. I suspect it may prove useful for
> the bytes() type as well).
If I'm foll
Greg Ewing wrote:
> Ron Adam wrote:
>
>> 1. Remove None stored as indices in slice objects. Depending on the step
>> value, Any Nones can be converted to 0 or -1 immediately,
>
> But None isn't the same as -1 in a slice. None means the end
> of the sequence, wh
Greg Ewing wrote:
> Ron Adam wrote:
>
>> And in addition to that... 0 is not the beginning if the step is -1.
>
> Negative steps are downright confusing however you
> think about them. :-)
Yes, and it seems to me it could be easier. Of course that would mean
changi
Guido van Rossum wrote:
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception? (We could even add three options: truncate, pad,
> error, with truncate being the default, and pad being the old map()
> and filter() behavior.)
Maybe it can be done with just two op
Josiah Carlson wrote:
> If views are always returned, then we can perform some optimizations
> (adjacent view concatenation, etc.), which may reduce running time,
> memory use, etc. d
Given a empty string and a view to it, how much memory do you think a
view object will take in comparison to th
Raymond Hettinger wrote:
>
>>> We could always rename raw_input() to input(). Just a thought. . .
>>>
>>
>> D'oh. Guido already said he doesn't like that idea :)
>>
>>
>
> FWIW, I think it is a good idea. If there is a little 2.x vs 3.0
> confusion, so be it. The use of input() functi
This was bit too brief I think...
Ron Adam wrote:
> How about...? (This isn't an area I'm real familiar with.)
>
>
> Replace __del__ with:
>
> a __final__ method and a __finalized__ flag. (or other equivalent names)
The __final__ method would need to b
Giovanni Bajo wrote:
> Since we are discussing Py3k here, I believe it is the right time to revive
> this discussion. The __close__ proposal I'm backing (sumed up in this mail:
> http://mail.python.org/pipermail/python-3000/2006-September/003892.html) is
> pretty similar to how Guido was proposing
Phillip J. Eby wrote:
> At 12:00 PM 10/14/2006 +0200, "Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
>> Ivan Krsti? wrote:
>>> Talin wrote:
>>> That'd be nice. And on that note, for the love of confused masses
>>> everywhere, can we please change the name of easy_install to something
>>> Python-specifi
Talin wrote:
> Now, that being said, I wouldn't have a problem with there being an
> "abstract filesystem object" that represents an entity on disk (be it
> file, directory, etc.), which would have a path inside it that would do
> some of the things you suggest.
I think this option should be e
Ka-Ping Yee wrote:
> On Fri, 3 Nov 2006, Greg Ewing wrote:
>>> Before it is reasonable to change the meaning of "global", we would
>>> need to have coherent answers to these questions:
>>>
>>> 1. What is the global namespace?
>> Under the proposal, there is no such thing as
>> "the" global nam
Mike Krell wrote:
>> How about [...] using 'parent' as the keyword?
>
> I once proposed 'parent' in a similar thread a long time ago.
>
> It's a non-starter because it's a commonly used variable name.
>
>Mike
I thought it might be.
How about. __parent__
Just kidding, (I think), of c
Greg Ewing wrote:
> Ron Adam wrote:
>
>> How about limiting nonlocal to just the immediate parent scope and using
>> 'parent' as the keyword?
>
> That could lead to confusing situations. What should
> the following do:
>
>def f():
&
Georg Brandl wrote:
> Ron Adam wrote:
>
>> I presume you meant:
>>
>> def f():
>> x = 42
>> def g():
>> def h():
>> parent x
>> x = 88
>>
>>
>> The x would be a new local x in fu
Mike Orr wrote:
> The multi-argument constructor is a replacement for joining paths.
> (The PEP says .joinpath was "problematic" without saying why.)This
> could theoretically go either way, doing either the same thing as
> os.path.join, getting a little smarter, or doing "safe" joins by
> dis
> [Mike Orr wrote:]
> In this vein, a common utility module with back-end functions would be
> good. Then we can solve the difficult problems *once* and have a test
> suite that proves it, and people would have confidence using any OO
> classes that are built over them. We can start by gathering
Greg Ewing wrote:
> Gustavo Niemeyer wrote:
>> Are you arguing that
>> pretty much every approach being discussed is bad and
>> we should instead implement something magically
>> transforming types?
>
> No, I'm questioning the need to do anything at all.
> I don't see a big problem that merits a h
Nick Coghlan wrote:
> Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> The deficiencies of email shouldn't be dictating the language.
>> The interpreter prompt is hardly part of the language,
>
> Except that the doctest module and the prevalence of interactive prompt
> snippets in the documentati
I don't normally start threads, but I wasn't sure who to post this as a reply
to. This thought or direction of discussion, seems like it may be a useful
viewpoint in the type/interface topics.
Python's syntax interacts strongly with a number of basic types. For example
(and in general) a
Bill Janssen wrote:
> Ron,
>
>> I'm wonder how many places in pythons syntax requires or produces specific
>> types. And if listing and organizing these commonly used "syntactically
>> necessary" types would be useful to determine the minimum list of ABC's.
>> (More
>> can always be added late
Mike Orr wrote:
> On 1/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 1/1/07, James Thiele <[EMAIL PROTECTED]> wrote:
>>> PEP 3100 states:
>>> None becomes a keyword [4] (What about True, False?)
>>>
>>> Has a decision been made?
>> No, but I think the argument for making True/False reserv
Raymond Hettinger wrote:
> P.S. A small side-benefit is it may put an end for interminable requests for
> a {:} or {/} notation for empty sets. There's not much need for a literal
> for a empty frozenset (use "not s" instead).
How about also removing the {} as an empty dictionary? Then bo
Raymond Hettinger wrote:
>> should the repr for a set be set({a, b, c})
>> instead of set([a, b, c])?
>
> FWIW, running eval() on the repr is slower and less memory efficient with
> curly braces than with the square brackets.
This is what I get.
>>> timeit.timeit("eval('frozenset({1,2,3})
Christian Heimes wrote:
> Stephen J. Turnbull wrote:
>> Mac OS X's open command does something according to extension:
>>
>> chibi:tmp steve$ echo 'print "hello, world"' >> hello.py
>> chibi:tmp steve$ python hello.py
>> hello, world
>> chibi:tmp steve$ open hello.py
>> chibi:tmp steve$
>>
>>
[EMAIL PROTECTED] wrote:
> >> It won't work in this case. Compilation of the module might well
> >> fail because of Python2/Python3 syntax differences.
>
> Leif> Well, then this isn't something to be implemented for python 2,
> Leif> it's something to consider for python 3 and g
Christian Heimes wrote:
> Mike Meyer wrote:
>> -2 on using the shebang line for this. The 2.X version-specific
>> binaries are python2.X, so to use that, you'd have to make the shebang
>> line invoke python2.X. Right now, if you upgrade an installation from
>> 2.X to 2.X+1, you can expect most of
Raymond Hettinger wrote:
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An obj
Abdallah El Guindy wrote:
Hey all
I know that the feature I am about to suggest may be minor and may have
a very low priority considering other issues to be discussed, however
I'll suggest it anyways..
Being a very frequent user of the interactive shell, I find it annoying
when I try to u
Guido van Rossum wrote:
> On 1/11/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I thinking that the 3.0.X version be considered a try it out (alpha) release
>> to
>> generate plenty of feed back, and the 3.1.X version be the first version
>> meant
>>
Jim Jewett wrote:
> Raymond Hettinger wrote:
>
>> Also, I'm wondering if the desire for 2.6 warnings is based on the notion
>> that
>> it will be possible to get large tools to work under both Py2.x and Py3.x.
>
> I had certainly assumed it would be possible.
>
> In fact, I had assumed that the
Tony Lownds wrote:
> http://mail.python.org/pipermail/python-dev/2007-January/070665.html
>
> What's the cost of keeping sys.exc_info() on 3.0? If that cost is a
> hindrance on 3.0, then
> fine, sys.exc_info() and the ability for module authors to use a
> single codebase on 2.x and
> 3.0 can
Andrew Koenig wrote:
>> I'm not proposing to remove the feature, however I'd like to see an
>> alternative method for declaring statements that cross a line boundary.
>> I seem to recall at one point someone suggesting the use of ellipsis,
>> which makes a lot of sense to me:
>>
>> sorted_resul
Delaney, Timothy (Tim) wrote:
> What I'm proposing is that the `super = super_factory()` line be
> implicit in this case, resulting in the following code behaving
> identically:
>
> class A(object):
> def f(self):
> def inner():
> return 'A' + super.f()
>
Raymond Hettinger wrote:
> [Collin Winter]
>> Put another way, a role is an assertion about a set of capabilities.
> . . .
>> If there's interest in this, I could probably whip up a PEP before the
>> deadline.
>
> +100 I'm very interested in seeing a lighter weight alternative to abc.py
> that:
Phillip J. Eby wrote:
> At 07:37 PM 5/1/2007 -0700, Guido van Rossum wrote:
>> That's one solution. Another solution would be to use GFs in Pydoc to
>> make it overloadable; I'd say pydoc could use a bit of an overhault at
>> this point.
>
> True enough; until you mentioned that, I'd forgotten th
Georg Brandl wrote:
> FWIW, I'm -1 on both proposals too. I like implicit string literal
> concatenation
> and I really can't see what we gain from backslash continuation removal.
>
> Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end
Benji York wrote:
> Ron Adam wrote:
>> The following inconsistency still bothers me, but I suppose it's an edge
>> case that doesn't cause problems.
>>
>> >>> print r"hello world\"
>>File "", line 1
>>
Raymond Hettinger wrote:
> [Andrew Koenig]
>> It has occurred to me that as Python stands today, an indent always begins
>> with a colon. So in principle, we could define anything that looks like an
>> indent but doesn't begin with a colon as a continuation. So the idea would
>> be that you can c
Greg Ewing wrote:
> Phillip J. Eby wrote:
>> For
>> example, objects to be documented with pydoc currently have to
>> reverse engineer a bunch of inspection code, while in a GF-based
>> design they'd just add methods.
>
> There's a problem with this that I haven't seen a good
> answer to yet. T
Jason Orendorff wrote:
> I think the gesture alone is worth it, even if no one ever used the
> feature productively. But people will. The cost to python-dev is low,
> and the cost to English-speaking users is very likely zero.
>
> What am I missing?
I don't think you're missing anything.
I th
Steven Bethard wrote:
> I actually wasn't able to find something I couldn't translate. It
> would be helpful to have another set of eyes if anyone has the time.
I have a patch against (*) 2.6 tokanize.py that ignores '\' characters in
raw strings. This has two effects. A matching quote, """,
uld make the patch against the py3k-struni branch
> instead of against the regular p3yk (sic) branch?
I can do that. :-)
> On 5/16/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Steven Bethard wrote:
>>
>> > I actually wasn't able to find something I couldn&#x
Guido van Rossum wrote:
> That would be great! This will automatically turn \u1234 into 6
> characters, right?
>
> Perhaps you could make the patch against the py3k-struni branch
> instead of against the regular p3yk (sic) branch?
Done. Patch number 1720390
https://sourceforge.net/tracker/index
Georg Brandl wrote:
> Ron Adam schrieb:
>> Guido van Rossum wrote:
>>> That would be great! This will automatically turn \u1234 into 6
>>> characters, right?
>> I'm not exactly clear when the '\u' characters get converted. There
>>
Alexandre Vassalotti wrote:
> On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> If "make clean" makes the problem go away, it's usually because there
>> were old .pyc files with incompatible byte code. We don't change the
>> .pyc magic number for each change to the compiler.
>
> Nope. It i
Neal Norwitz wrote:
> On 6/5/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Alexandre Vassalotti wrote:
>> > On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> >> If "make clean" makes the problem go away, it's usually because there
Guido van Rossum wrote:
> On 6/7/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
>> On 6/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> It's time to look at the original traceback (attached as "tb", after
>>> fixing the formatting problems). it looks like any call to
>>> encodings.n
Martin v. Löwis wrote:
> FWIW, for me the build error goes away when I unset
> LANG, so that the error occurs during build definitely
> *is* a locale issue.
Yes, and to pin it down a bit further...
This avoids the problem by setting the language to the default "C" which is
a unicode string and
Guido van Rossum wrote:
>> The os.environ.get() method probably should return a unicode string. (?)
>
> Indeed -- care to contribute a patch?
I thought you might ask that. :-)
It looks like os.py module imports a 'envirion' dictionary from various
sources depending on the platform.
po
Guido van Rossum wrote:
> On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >> The os.environ.get() method probably should return a unicode
>> string. (?)
>> >
>> > Indeed -- care to contribute a patch?
>>
>> Ideally, such a patch would make use of the Win32 Unicode API for
>> environment
ake a new remove_raw_escapes patch so it applies cleanly.
I'm trying to track down why my patched version of test_tokenize.py passes
sometimes but not at others. (I think it's either a tempfile or string io
issue, or both.) This was what initiated the above suggestion.
;-)
Cheers,
Guido van Rossum wrote:
> On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>>
>>
>> Guido van Rossum wrote:
>> > I couldn't get this exact patch to apply, but I implemented something
>> > equivalent in the py3kstruni branch. See revisio
Guido van Rossum wrote:
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
Looking at the overall structure of os.py makes me think the platform
specific code could be abstracted out a bit further. Possibly have one
public "platform" module (or package) that is an alias or bu
Guido van Rossum wrote:
> On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Well I can see where a str8() type with an __incoded_with__ attribute
>> could
>> be useful. It would use a bit more memory, but it won't be the
>> default/primary string typ
Martin v. Löwis wrote:
Then bytes can be bytes, and unicode can be unicode, and str8 can be
encoded strings for interfacing with the outside non-unicode world. Or
something like that.
>>> Hm... Requiring each str8 instance to have an encoding might be a
>>> problem -- it means yo
Martin v. Löwis wrote:
>> This was in the context that it is decided by the community that a st8
>> type is needed and it does not go away.
>
> I think *that* context has not occurred. People wanted a read-only
> bytes type, not a byte-oriented character string type.
>
>> The alternative is for
Guido van Rossum wrote:
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
Attached both the str8 repr as s"..." and s'...', and the latest
no_raw_escape patch which I think is complete now and should apply
with no
problems.
I like the str8 repr patch enough to c
Guido van Rossum wrote:
Thanks for the patches! Applied, except for the change to
tokenize.py; instead, I changed test_tokenize.py to use io.StringIO.
--Guido
Glad to have the opportunity to help make the future happen. ;-)
This next one converts unicode literals in tokenize.py and it's t
Brett Cannon wrote:
> On 6/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 6/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
So, my question is how best to handle this test (and thus other tests
like it). Should it just continue to fail until someone fixes
_bsddb.c to
Bill Janssen wrote:
>> I think you were missing my point, which is that sum
>> doesn't and shouldn't necessarily have the same
>> semantics as map(+).
>
> It's not that I don't understand your argument, Steve.
>
> I just don't find it effective. If we are going to distinguish
> between "arithm
Steve Howell wrote:
> --- Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>
>> Bill Janssen wrote:
>>>> I think you were missing my point, which is that
>> sum
>>>> doesn't and shouldn't necessarily have the same
>>>> seman
Mark Hammond wrote:
> Barry writes:
>
>> On Jun 28, 2007, at 4:04 PM, Chris McDonough wrote:
>> A good test suite can benefit from both doctests and unittests and I
>> don't think unittest will ever go away (nor should it), but in my
>> latest work I'm opting more and more for doctests.
>
> I fi
Barry Warsaw wrote:
> However, .setdefault() is a horrible name because it's not clear from
> the name that a 'get' operation also happens.
The return value of .setdefault() could be changed to None, then the name
would be correct.
And then a helper function could fill the current use case of
Guido van Rossum wrote:
> We could easily change this to return a
> writable mapping that's not a dict at all but a "view" on the locals
> just as dict.keys() returns a view on a dict. I don't see why locals()
> couldn't return the object used to represent the namespace, but I
> don't see that it
Phillip J. Eby wrote:
> At 07:40 PM 7/9/2007 -0500, Ron Adam wrote:
>
>> Guido van Rossum wrote:
>>
>>> We could easily change this to return a
>>> writable mapping that's not a dict at all but a "view" on the locals
>>> just as
Greg Ewing wrote:
> Nick Coghlan wrote:
>> Py3k strings are unicode, so returning a string would mean you just have
>> to encode it again using the ascii codec to get the bytes to put on the
>> wire.
>
> I still believe that producing a string is conceptually
> the right thing to do. The point
Talin wrote:
> I had a long discussion with Guido today, where he pointed out numerous
> flaws and inconsistencies in my PEP that I had overlooked. I won't go
> into all of the details of what he found, but I'd like to focus on what
> came out of the discussion. I'm going to be updating the PE
Talin wrote:
> Ron Adam wrote:
>
>> Splits the item and it's formatter. The alignment is more of a
>> container property or feild property as you pointed out further down.
>>
>> So maybe if you group the related values together...
>>
>> {valu
Talin wrote:
> (I should also mention that "a:b,c" looks prettier to my eye than
> "a,b:c". There's a reason for this, and its because of Python syntax.
> Now, in Python, ':' isn't an operator - but if it was, you would have to
> consider its precedence to be very low. Because when we look at
Talin wrote:
> Ron Adam wrote:
>> After a fair amount of experimenting today, I think I've found a nice
>> middle ground that meets some of what both you and Guido are looking
>> for. (And a bit my own preference too.)
>
> First off, thank you very much fo
Guido van Rossum wrote:
> I have no time for a complete response, but a few quickies:
>
> - The more I think about it the, more I think putting knowledge of
> floating point formatting into the wrapper is wrong. I really think we
> should put this into float.__format__ (and int.__format__, and
>
Talin wrote:
> What's missing, however, is a description of how all of this interacts
> with the __format__ hook. The problem we are facing right now is
> sometimes we want to override the __format__ hook and sometimes we
> don't. Right now, the model that we want seems to be:
>
> 1) High
Greg Ewing wrote:
> Ron Adam wrote:
>
>> '{0:10;20,f.2}'
>>
>> Works for me.
>
> It doesn't work for me, as it breaks up into
>
>0:10; 20,f.2
>
> i.e. semicolons separate more strongly than commas
> to my eyes.
And afte
Ron Adam wrote:
> An alternative I thought of this morning is to reuse the alignment symbols
> '^', '+', and '-' and require a minimum width if a maximum width is specified.
One more (or two) additions to this...
In the common cases of generating
Guido van Rossum wrote:
> On 8/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Ron Adam wrote:
>>> Which would result in a first column that right aligns, a second column
>>> that centers unless the value is longer than 100, in which case it right
>>> a
1 - 100 of 143 matches
Mail list logo
