The standard high-bit-density encoding past base-64 is base-85
(http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes
as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works,
is an RFC somewhere, ... and maybe should find it's way into the
Python standard library's codec p
On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>> The standard high-bit-density encoding past base-64 is base-85
>> (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes
>> as 5 ascii by
On Mon, Aug 11, 2008 at 8:43 AM, zooko <[EMAIL PROTECTED]> wrote:
> On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote:
>
>> Martin v. Löwis v.loewis.de> writes:
>>>
>>> P.S. Just in case it isn't clear: I would oppose any specific proposal
>>> to add this Ascii85 algorithm to the standard library.
On Thu, Sep 4, 2008 at 10:03 AM, <[EMAIL PROTECTED]> wrote:
>
>> Compared to sqlite, you don't need to know SQL, you can finetuning
>> (for example, using ACI instead of ACID, deciding store by store), and
>> you can do replication and distributed transactions (useful, for
>> examp
On Thu, Sep 4, 2008 at 5:02 PM, <[EMAIL PROTECTED]> wrote:
>
>me> I suggested in another message (perhaps on another thread) that
>me> maybe a dbm.sqlite module would be worth having.
>
> http://bugs.python.org/issue3783
I did a similar thing today. I can post my version later today.
-
On Thu, Sep 11, 2008 at 2:40 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote:
> As far as I can see, the specification of the dbm interface is the module
> docstring in dbm/__init__.py, which reads:
>
> """
> [...]
> It has the following interface (key and data are strings):
>
>d[key] = data
On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> In Python 2.x when iterating over a weak key dictionary for example, the
> common
> idom for doing that was calling dictionary.keys() to ensure that a list of all
> objects is returned it was safe to ite
On Sat, Sep 13, 2008 at 5:21 PM, Scott David Daniels
<[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>>
>> On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher wrote:
>>>
>>> Iterating over weak key dictionaries might not be the most common task
>>&
On Mon, Sep 22, 2008 at 5:15 PM, Brendan O'Connor <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I was enjoying reading Raymond Hettinger's Objects/dictnotes.txt, and
> was wondering, which (if any) of its suggestions implemented? I see
> most of it was written back in 2003.
If I remember correctl
On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Second, I would like to help to fix all Python security issues. It looks like
> Python community isn't very reactive (proactive?) about security. Eg. a DoS
> was reported in smtpd server (integrated to Python)... 15 months
On Mon, Sep 29, 2008 at 12:02 PM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> On 27 Set, 20:04, "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
>> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner
>>
>> <[EMAIL PROTECTED]> wrote:
>> > Sec
On Wed, Oct 8, 2008 at 10:30 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Sidnei da Silva <[EMAIL PROTECTED]> wrote:
>
>> https://bugs.edge.launchpad.net/zope2/+bug/280020
>
> I think there are real issues here with both asynchat and Medusa.
> Asynchat has been heavily re-written, and the "ac_out_
On Sun, Nov 2, 2008 at 3:51 PM, <[EMAIL PROTECTED]> wrote:
>
>Antoine> I think it is important to remind that the GIL doesn't prevent
>Antoine> (almost) true multithreading. The only thing it prevents is
>Antoine> full use of multi-CPU resources in a single process.
>
> I believe every
On Mon, Nov 3, 2008 at 10:59 AM, Curt Hagenlocher <[EMAIL PROTECTED]>wrote:
> On Mon, Nov 3, 2008 at 11:50 AM, Josiah Carlson <[EMAIL PROTECTED]>wrote:
>
>> On Sun, Nov 2, 2008 at 3:51 PM, <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>Antoine&g
On Tue, Nov 4, 2008 at 5:31 AM, Leonardo Santagada <[EMAIL PROTECTED]> wrote:
>
> On Nov 4, 2008, at 12:11 AM, Josiah Carlson wrote:
>
>> There is no shortage of algorithms (such as matrix multiplication) that
>> are parallelizable but not particularly good
Would anyone mind terribly if I backported a version of:
http://bugs.python.org/issue4501 to 2.4 and 2.5?
It fixes some strange duplicate data issues on poll() with packets
with a nonstandard flag set.
- Josiah
On Sat, Dec 13, 2008 at 2:55 PM, "Martin v. Löwis" wrote:
> Christian Heimes wrote:
On Mon, Dec 15, 2008 at 1:14 PM, Victor Stinner
wrote:
> Le Monday 15 December 2008 19:50:42 Josiah Carlson, vous avez écrit :
>> Would anyone mind terribly if I backported a version of:
>> http://bugs.python.org/issue4501 to 2.4 and 2.5?
>
> First the patch have be reviewed
Quick questions:
Is mmap's inability to be subclassed a feature or bug?
Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and
others) a feature or bug?
I would imagine they are bugs, but I just wanted to make sure and post
the report/request in the proper location.
Thank you,
Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson <[EMAIL PROTECTED]> writes:
> > Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and
> > others) a feature or bug?
>
> I'm not entirely sure about this, tho
Titus Brown <[EMAIL PROTECTED]> wrote:
>
> -> > 1067760 -- float-->long conversion on fileobj.seek calls, rather than
> -> >float-->int. Permits larger floats (2.0**62) to match large
> -> >int (2**62) arguments. rhettinger marked as "won't fix" in
> -> >the original bug
Scott David Daniels <[EMAIL PROTECTED]> wrote:
>
> I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary
> motivation is that Project Gutenberg seems to be starting to use BZIP2
> compression for some of its zips. What other wish list things do
> people around here have for zipfile
Tim Peters <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > Let's get rid of unbound methods. When class C defines a method
[snip]
> Really? Unbound methods are used most often (IME) to call a
> base-class method from a subclass, like my_base.the_method(self, ...).
> It's especially easy to forget
te `self, ` there, and the
> >> exception msg then is quite focused because of that extra bit of
> >> type checking. Otherwise I expect we'd see a more-mysterious
> >> AttributeError or TypeError when the base method got around to
> >> trying to do something
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Since we already have the islice iterator, what's the point?
>
> I'd like to see iterators become as easy to work with as lists are. At the
> moment, anything that returns an iterator forces you to use the relatively
> cumber
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 01, 2005 at 11:11:37AM -0500, Neal Becker wrote:
> > complex ('(2+2j)')
> > Traceback (most recent call last):
> > File "", line 1, in ?
> > ValueError: complex() arg is a malformed string
> >
> > Whatever format is used for output sho
James Y Knight <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 14, 2005, at 10:41 AM, Tim Peters wrote:
>
> >> Wouldn't it be more elegant to make builtin_id() return an unsigned
> >> long integer?
> >
> > I think so. This is the function ZODB 3.3 uses, BTW:
> >
> > def positive_id(obj):
> > """Re
In a recent discussion in a SF patch, I noticed that PEP 328* only seems
to support relative imports within packages, while bare import
statements use the entirety of sys.path, not solving the shadowing of
standard library module names.
I have certainly forgotten bits of discussion from last spri
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > In a recent discussion in a SF patch, I noticed that PEP 328* only seems
> > to support relative imports within packages, while bare import
> > statements use the entirety of sys.path, not solving the shadowing of
> > standard library module names.
>
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Sure. There are lots of FAQs whose answer is not "Python will have to change".
And I'm not saying Python has to change either, hence the initial query
and planned PEP. Boiling it down; if we could change import in such a
way that made standard librar
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> [Josiah Carlson]
> > > if we could change import in such a
> > > way that made standard library imports different from standard library
> > > imports, we could
>
> [Greg Ewing]
> > ...go on to pro
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
>
> [BJörn Lindqvist]
> > I would LOVE for **kwargs to be an ordered dict. It would allow me to
> > write code like this:
> >
> > .class MyTuple:
> > .def __init__(self, **kwargs):
> > .self.__dict__ = ordereddict(kwargs)
>
> This doesn
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> I would like to get some feedback on a proposal to introduce
> smalltalk/ruby-like "code blocks" to python. Code blocks are, among other
> things, a clean way to solve the "acquire/release" problem [1][2]. This
> proposal also touches on some of the pr
Brian Sabbey <[EMAIL PROTECTED]> wrote:
>
> On Fri, 11 Mar 2005, Josiah Carlson wrote:
>
> > My first reaction to the proposal was "ick". Why? Because every time
> > I've seen a mechanism for modifying the internals of generators
> > construct
Brian Sabbey <[EMAIL PROTECTED]> wrote:
>
> On Sat, 12 Mar 2005, Josiah Carlson wrote:
>
> > I say it is magical. Why? The way you propose it, 'yield' becomes an
> > infix operator, with the name provided on the left being assigned a
> > value
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> On Sat, 12 Mar 2005, Josiah Carlson wrote:
>
> > I stand by my "clever hack" statement, and I will agree to disagree with
> > you on it, like I agree to disagree with you about both the necessity of
> > passing a
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Brian Sabbey wrote:
>
> > How about something like below? In the same way
> > that "self" is passed "behind the scenes" as the first argument, so can
> > the thunk be.
> >
> > with stopwatch() result dt:
> > a()
> > b()
> > print 'it took', d
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Since PEP 310 was already mentioned, can we just say that the discussion
> > can be boiled down to different ways of spelling __enter__/__exit__ from
> > PEP 310?
>
> It's
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> >>Josiah Carlson wrote:
> >>
> >>
> >>>Since PEP 310 was already mentioned, can we just say that the discussi
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> [snip]
> >>well, I think some people desire a more streamlined way of writing code
> >>like:
> >>
> >>def f(...)
>
Jp Calderone <[EMAIL PROTECTED]> wrote:
>
> On Thu, 17 Mar 2005 09:01:27 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > >
> > > Josiah Carlson wrote:
> > > >
> > >
Good day,
I just noticed that decoration of classes was not included with the
@decoration syntax that made it into Python 2.4. While I understand
that class decoration was not a part of PEP 318, I remember people were
interested in decorating classes for all sorts of reasons, among them as
a pre
Paul Moore <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Mar 2005 10:33:53 -0600 (CST), Ka-Ping Yee
> <[EMAIL PROTECTED]> wrote:
> > It dawned on me that you could use this idea to make the whole
> > filter/lambda experience vastly more pleasant. I whipped up a quick
> > implementation:
> >
> >
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Mar 2005, Josiah Carlson wrote:
> > Paul Moore <[EMAIL PROTECTED]> wrote:
> > > I thought about it, but couldn't convince myself that it would work
> > > properly in all cases. I was thi
Tim Lesher <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Mar 2005 22:58:51 +0100, Florian Schulze
> <[EMAIL PROTECTED]> wrote:
> > BTW, Herman Toothrot is from Monkey Island.
>
> Right. That's what leads me to believe 1) it's not a serious post,
> and 2) it's from someone who's old enough to know b
Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson:
>
> > I just noticed that decoration of classes was not included with the
> > @decoration syntax that made it into Python 2.4. ...
>
> > Is the fact that it didn't make it into 2.4 due to a
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>
> Given the ideas so far, would it possible to:
>
> def meta(cls):
> ...
>
> @meta
> class X(...):
> ...
It is not implemented in Python 2.4. From what I understand, making it
happen in Python 2.5 would not be terribly difficult. The qu
Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson writes:
>
> [... stuff about reST and TeX ...]
> > While I have not used it often, I have done the equivalent of decorating
> > classes; it is as natural (though perhaps not quite as usefu
Steve Holden <[EMAIL PROTECTED]> wrote:
[...]
> Having to write
>
> [x for x in seq]
>
> to produce a copy of a list doesn't seem that outrageous to me, and I
> don't find the predicate-less case of your proposal that convincing:
>
> [x in seq]
>
> seems somehow too terse.
And is a
Nicolas Fleury <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> import re2
> buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping'
> regex='^((?P(?P\d+) (?P[^,]+))(, )?)*$'
> pat2=re2.compile(regex)
> x=pat2.extract(buf)
If one wanted to match the API of t
[Guido van Rossum]
> @EXPR:
> CODE
>
> would become something like
>
> def __block():
> CODE
> EXPR(__block)
>
> I'm not yet sure whether to love or hate it. :-)
Is it preferable for CODE to execute in its own namespace (the above
being a literal translation of the given code), or for
Michael Walter <[EMAIL PROTECTED]> wrote:
>
> On 4/19/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > > RSMotD (random stupid musing of the day): so I wonder if the decorator
> > > syntax couldn't be extended for this kind of thing.
> > >
> > > @acquire(myLock):
> > > code
> > > code
>
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
>
>
> >
> >
> >def do():
> >print "setup"
> >try:
> >yield None
> >finally:
> >print "tear down"
> >
> > doesn't quite work (if it did, all you would need is syntactic sugar
> > for "for
> > dummy in"
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > See the previous two discussions on thunks here on python-dev, and
> > notice how the only problem that seem bettered via blocks/thunks /in
> > Python/ are those which
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> [Brett]
> > I think I agree with Samuele that it would be more pertinent to put all of
> > this
> > effort into trying to come up with some way to handle cleanup in a
> > generator.
>
> I.e. PEP 325.
>
> But (as I explained, and you agree) that
[EMAIL PROTECTED] (holger krekel) wrote:
> basically translates to:
>
> if hasattr(x, '__enter__'):
> x.__enter__()
> try:
> ...
> except:
> if hasattr(x, '__except__'): x.__except__(...)
> else: x.__exit__()
> else:
> x.__exit__()
Toby Dickenson <[EMAIL PROTECTED]> wrote:
>
> On Sunday 24 April 2005 07:42, Nick Coghlan wrote:
> > Shane Hathaway wrote:
>
> > > While we're on the subject of block handler method names, do the method
> > > names need four underscores? 'enter' and 'exit' look better than
> > > '__enter__' and
[Guido]
> OK, now you *must* look at the Boo solution.
> http://boo.codehaus.org/Syntactic+Macros
That is an interesting solution, requiring macro writers to actually
write an AST modifier seems pretty reasonable to me. Whether we want
macros or not...
- Josiah
__
Jason Diamond <[EMAIL PROTECTED]> wrote:
>
> Paul Svensson wrote:
>
> > You're not mentioning scopes of local variables, which seems to be
> > the issue where most of the previous proposals lose their balance
> > between hairy and pointless...
>
> My syntax is just sugar for nested defs. I a
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I've written a PEP about this topic. It's PEP 340: Anonymous Block
> Statements (http://python.org/peps/pep-0340.html).
>
> Some highlights:
>
> - temporarily sidestepping the syntax by proposing 'block' instead of 'with'
> - __next__() argument s
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Ouch. Another bug in the PEP. It was late. ;-)
>
> The "finally:" should have been "except StopIteration:" I've updated
> the PEP online.
>
> > Unless it is too early for me, I believe what you wanted is...
> >
> > itr = iter(EXPR1)
> >
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That actually looks pretty reasonable.
>
> Hmmm. "Patterns of structure." Maybe we could call it a
> "struct" statement.
>
> struct opening(foo) as f:
>...
>
> Then we could confuse both C *and* Ruby programmers at
> the same time! :-)
And Py
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> [Nicolas Fleury]
> > I would prefer something that would be
> > understandable for a newbie's eyes, even if it fits more with common
> > usage than with the real semantics behind it. For example a Boost-like
> > keyword like:
> >
> > scoped EXPR a
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Then, in Py3K, finalisation could simply become the default for loop
> behaviour.
> However, the '__finalise__' flag would result in some impressive code bloat,
> as
> any for loop would need to expand to:
>
> itr = iter(EXPR1)
> if getattr(
:
ex_block_2 = True
break
arg = None
BLOCK1
if ex_block_2:
BLOCK2
Josiah Carlson wrote:
> Indeed, I also mentioned this on Wednesday.
Though I was somewhat incorrect as code examples I offere
"m.u.k" <[EMAIL PROTECTED]> wrote:
> Currently Py_FatalError only dumps the error to stderr and calls abort().
> When doing quirky things with the interpreter, it's so annoying that process
> just terminates. Are there any reason why we still dont have a simple
> callback to hook Py_FatalError.
"m.u.k" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Guido van Rossum <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Your efforts would be better directed towards fixing the causes of the
> > fatal errors.
> >
> > I see no need to hook Py_FatalError, but since it's open source, you
>
"m.u.k" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Offering any hook for Py_FatalError may not even be enough, as some of
> > those errors are caused by insufficient memory. What if a
"Edward C. Jones" <[EMAIL PROTECTED]> wrote:
> 3. Add full "tostring" and "fromstring" capabilities for Python numeric
> types. "tostring(x)" would return a string containing the binary
> representation of x. For example, if x is a Python float, "tostring(x)"
> would have eight characters. "fr
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Wed, 4 May 2005, Shane Hathaway wrote:
> >
> > for name in filenames:
> > opening(name) as f:
> > if f.read(2) == 0xFEB0:
> > break for
>
> continue with 2
>
There is something aboutthat I just don't
Josiah Carlson <[EMAIL PROTECTED]> wrote:
unsigned
vv
> For 64 bit signed integers:
> struct.pack("Q",...)
> struct.unpack("Q",...)
My fingers were typing too fast (I do much work with unsigned 64 bit
integers, but not m
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Thu, 5 May 2005, Josiah Carlson wrote:
> > Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > > continue with 2
> >
> > There is something aboutthat I just don't like.
>
> Just to clarify: if
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
>
> > [...]
> > The whole PEP draft can be found here:
> > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> > [...]
> > Used as follows::
> >
> > for del auto_retry(3, IOError):
> > f = urllib.urlo
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > You should know why that can't work. If I pass a list, is a list an
> > iterator? No, but it should neither be created nor destroyed before or
> > after.
> >
> > The discussi
Ron Adam <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >>I think a completely separate looping or non-looping construct would be
> >>better for the finalization issue, and maybe can work with class's with
> >>__exit__ as well as generators.
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > It's not a matter of 'will they be finalized', but instead a matter of
> > 'will they be finalized in a timely manner'. From what I understand;
> > upon garbage collection, an
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
> end. The list itself remains untouched.
My mistake, I did not understand your use of pronouns.
- Josiah
___
Python-Dev mailing list
Ron Adam <[EMAIL PROTECTED]> wrote:
> There's also the possibility to use conditional looping based on the
> value returned from the generator.
>
> do VAR from EXPR if VAR==CONST:
> BLOCK
>
> This is a bit verbose, but it reads well. :-)
Reading well or not, this is not really an option fo
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should. The various use cases involve multi-part transactions and
> > such.
[snip looping block discussion]
> For th
Ron Adam <[EMAIL PROTECTED]> wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should. The various use cases involve multi-part transactions and
> > such.
>
> I think so now too, I had thought as Nick does earlier this week that
> the non-looping version
Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
> > Josiah Carlson wrote:
>
> >> This has the benefit that an arbitrary block of code can be named,
> >> and a named TerminateBlock used to exit it.
>
> >> ... I susp
Ron Adam <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Ron Adam <[EMAIL PROTECTED]> wrote:
> >
> >> There's also the possibility to use conditional looping based on the
> value returned from the generator.
> &g
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > I wasn't expressing my opinion, I was attempting to express as to where
> > the discussion went and concluded. I honestly can't remember having an
> > opinion on the subject, but I
Shane Hathaway <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
> > That would be good, in my opinion. I updated PEP 3XX to use this idea:
> > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> >
> > With that update (to version 1.6), PEP 3XX is basically PEP 343, but
> > injecting
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Sun, 15 May 2005, Shane Hathaway wrote:
> > You might add to the PEP the following example, which could really
> > improve the process of building GUIs in Python:
> >
> > class MyFrame(Frame):
> > def __init__(self):
> > with P
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
>
> On Monday 30 May 2005 17:06, Raymond Hettinger wrote:
> > There's no harm in having these surface. If the category is accurate,
> > let's use it. If the bug is out of date, we can mark it as such and
> > close it.
>
> While we can't (and s
Fernando Perez wrote:
> Skip Montanaro wrote:
>
>
>>I wouldn't mind a stdlib that defined a set of top-level packages (some of
>>which might be wholly unpopulated by modules in the standard distribution)
>>It might, for example, define a gui package and gui.Tkinter and gui._tkinter
>>modules, lea
Fernando Perez wrote:
> Josiah Carlson wrote:
>>Fernando Perez wrote:
>>>I've wondered if it wouldn't be better if the std lib were all stuffed into
>>>its own namespace:
>>>
>>>from std import urllib
>>>
>>>If a more stru
Ron Adam wrote:
[snip]
> Having less in the core distribution means smaller complete applications
> to install when py2exe is used. There also needs to be some assurance
> that the standard library has as few bugs in it as possible. The more
> that's added to it, the more work and testing to d
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Raymond Hettinger wrote:
> > More than case-statement semantics or PEP343, I wish for a dowhile
> > statement.
> >
> > The most straight-forward way is to put the conditional expression at
> > the beginning of the block with the understanding that a do
Charles Cazabon <[EMAIL PROTECTED]> wrote:
> Indeed. The original poster seems to want something that would work (not
> necessarily look) like this:
>
> do:
>
> while
>
> with executed once prior to first being tested. But the
> above is ugly, and you can get much the same effect
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> There may still be a use for a rational module in the standard library,
> but builtin support is no longer needed or desirable.
Sounds good.
> The rational proposal also has an intrinsic weakness shared with Java's
> prior versions of BigDecimal w
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Maybe anonymus function closures should be pushed forward right now not
> only syntactically? Personally I could live with lambda or several
> of the alternative syntaxes listed on the wiki page.
> But asking for a favourite syntax I would skip the "def"
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > Kay Schluehr <[EMAIL PROTECTED]> wrote:
> >> The arrow is a straightforward punctuation for function definitions.
> >> Reusing existing keywords for different semantics
Simon Wittber <[EMAIL PROTECTED]> wrote:
> > Why this discussion of yet another serialization format?
>
> Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
> XML can be bloated, and XML+gzip is quite slow.
>
> Do size,speed, and security features have to mutually exclusive? No,
Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Donovan Baarda wrote:
> >
> >>As I see it, a lambda is an anonymous function. An anonymous function is
> >>a function without a name.
> >
> >
> > And here we see why I'm such a fan of the term 'deferred expression'
> > instea
Keith Dart <[EMAIL PROTECTED]> wrote:
> Therefore, I would like to ask here if anyone has already started
> something like this? If not, I will go ahead and do it (if I have time).
If all you need to do is read or write C-like types to or from memory,
you should spend some time looking through t
James Y Knight <[EMAIL PROTECTED]> wrote:
> I like it, it makes sense. Unicode strings are simply not allowed as
> arguments to the byte constructor. Thinking about it, why would it be
> otherwise? And if you're mixing str-strings and unicode-strings, that
> means the str-strings you're some
Ron Adam <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Ron Adam wrote:
> >> b = bytes(0L) -> bytes([0,0,0,0])
> >
> > No, bytes(0L) --> TypeError because 0L doesn't implement
> > the iterator protocol or the buffer interface.
>
> It wouldn't need it if it was a direct C memory copy.
Y
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
>
> > Also the pseudo-encodings ('hex',
> > 'rot13', 'zip', 'uu', etc.) generally scare me.
>
> I think these will have to cease being implemented as
> encodings in 3.0. They should really never have been
> in the first place.
I wo
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > They may not be encodings of _unicode_ data,
>
> But if they're not encodings of unicode data, what
> business do they have being available through
> someunicodestring.encode(...)?
I
201 - 300 of 548 matches
Mail list logo
