On 12/07/2011 11:31 PM, Chris McDonough wrote:
All I can really offer is my own experience here based on writing code
that needs to straddle Python 2.5, 2.6, 2.7 and 3.2 without use of 2to3.
Having u'' work across all of these would mean porting would not require
as much eyeballing as code modifi
...
___
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
ranjith kannikara wrote:
As a student I am not familiar with Restricted Python and python AST
implementation.And in need of help to start the Restricted Python
implementation.
Here is some context for Python-Dev.
RestrictedPython is a custom Python compiler that, when combined with a
restrict
Adam Olsen wrote:
> Since they're not going to be accepted into python anyway, the
> implementation is off-topic for python-dev. Please take them up
> elsewhere (such as my offer to discuss in private.)
I was aware of Guido's earlier rejections, but I figured the rejection
was due to the risky im
Shane Hathaway wrote:
> Shane Hathaway wrote:
>> I'm interested in seeing a good way to write tail calls in Python. Some
>> algorithms are more readable when expressed using tail recursion.
>
> About ten seconds after I wrote the previous message, I realized two things:
Shane Hathaway wrote:
> I'm interested in seeing a good way to write tail calls in Python. Some
> algorithms are more readable when expressed using tail recursion.
About ten seconds after I wrote the previous message, I realized two things:
- It's easy to write "return Retu
Hello,
I'm interested in seeing a good way to write tail calls in Python. Some
algorithms are more readable when expressed using tail recursion.
I know tail call optimization has been discussed before [1], but I would
like to consider a different approach. The previous discussion centered
on im
Anthony Baxter wrote:
> On Saturday 01 July 2006 12:55, Guido van Rossum wrote:
>> It's up to the release manager now to decide whether the pitchforks
>> at Google or the pitchforks in the larger Python community are
>> sharper. ;-)
>
> At this point, I think removing the warning code is the prude
Noam Raphael wrote:
> 2006/6/17, "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> Noam Raphael wrote:
>>> I meant the extra code for writing a special class to handle scalars,
>>> if I decide that the "x[()]" syntax is too ugly or too hard to type,
>>> so I write a special class which will allow the synta
Vinay Sajip wrote:
> On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>>- The logging.config.fileConfig function has bare excepts that hide
>>configuration errors. I'd like to remove the bare excepts and break up
>>fileConfig for clarity.
>
> I'v
Tim Peters wrote:
> [Shane Hathaway]
>
>>What is the time frame for Python 2.5? If I finish soon and the changes
>>are not disruptive, do I have enough time for my changes to make it into
>>2.5?
>
>
> Yup! 2.5 hasn't even had an alpha release yet, a
Neal Norwitz wrote:
> On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>
>>I'd like to create a patch for the logging package, but before I do, I
>>need to know whether someone else is working on the package and whether
>>my patch is likely to be accepte
I'd like to create a patch for the logging package, but before I do, I
need to know whether someone else is working on the package and whether
my patch is likely to be accepted. Is there another group I should talk to?
Specifically, I want to change the following:
- The logging.config.fileConf
Ian Bicking wrote:
> Right now most people who might be willing to contribute to the Python
> documentation don't. Well, "most don't" is an understatement. "Hardly
> any" would be more accurate. If just a small portion of people could
> contribute fairly easily that would be a big step forwar
Antoine Pitrou wrote:
>>I'd be happy to explain how
>>ZODB solves those problems, if you're interested.
>
>
> Well, yes, I'm interested :)
> (I don't anything about Zope internals though, and I've never even used
> it)
Ok. Quoting your list:
> To apply the same thing to Python you would at l
Antoine Pitrou wrote:
> A relational database has a very strict and regular data model. Also, it
> has transactions. This makes it easy to precisely define concurrency at
> the engine level.
>
> To apply the same thing to Python you would at least need :
> 1. a way to define a subset of the curr
Bruce Eckel wrote:
> But. I do happen to have contact with a lot of people who are at the
> forefront of the threading world, and *none* of them (many of whom
> have written the concurrency libraries for Java 5, for example) ever
> imply that threading is easy. In fact, they generally go out of the
Bruce Eckel wrote:
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
>
> What I'd really like to figure out is the "pythonic" solution for
> concurrency. Guido
Guido van Rossum wrote:
> On 9/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>string.Template is a bit too simplified. But perhaps it can be adapted.
>>We still want some way to express %r, %6.2f, etc.Since string
>>formatting has been around since Tim was in diapers, we should probab
Greg Ewing wrote:
> LD "Gus" Landis wrote:
>
>>.piece() can be both a verb and a noun
>
>
> Er, pardon? I don't think I've ever heard 'piece' used
> as a verb in English. Can you supply an example sentence?
"After Java splintered in 20XX, diehard fans desperately pieced together
the remaining
Terry Reedy wrote:
> "Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>You can do both: make partition() return a sequence with attributes,
>>similar to os.stat(). However, I would call the attributes "before",
>
Ron Adam wrote:
> For cases where single values are desired, attribues could work.
>
> Slicing:
> line = line.partition(';').head
> line = line.partition('#').head
>
> But it gets awkward as soon as you want more than one.
>
> sep, port = host.partition(':').head, host.pa
Pierre Barbier de Reuille wrote:
>
> Shane Hathaway a écrit :
>>Are you sure? I would instead expect to find a .partition method on a
>>regexp object:
>>
>> head, sep, tail = re.compile(sep+'.'*offset).partition(some_str)
>
>
> Well, to be cons
Eric Nieuwland wrote:
> Pierre Barbier de Reuille wrote:
>
>>Or you want to have some "partition" method which accept regular
>>expressions:
>>
>>head, sep, tail = some_str.partition(re.compile(sep+'.'*offset))
>
>
> Neat!
> +1 on regexps as an argument to partition().
Are you sure? I would in
Delaney, Timothy (Tim) wrote:
> I think that one of the things I have against it is that most times I
> type it, I get a typo. If this function is accepted, I think it will
> (and should!) become one of the most used string functions around. As
> such, the name should be *very* easy to type.
FWIW,
Niko Matsakis wrote:
>>
>> txn = new_transaction()
>> try:
>> txn.begin()
>> rtn = do_work()
>> finally:
>> if exception_occurred():
>> txn.abort()
>> else:
>> txn.commit()
>> return rtn
>>
>
> Couldn't you just do:
>
> txn = new_transaction ()
> try
Barry Warsaw wrote:
> I agree about bare except, but there is a very valid use case for an
> except clause that catches every possible exception. We need to make
> sure we don't overlook this use case. As an example, say I'm building a
> transaction-aware system, I'm going to want to write code l
Martin v. Löwis wrote:
> So I would propose the syntax
>
> lst.sort(key=virtual.lower) # where virtual is functional.virtual
Ooh, may I say that idea is interesting! It's easy to implement, too:
class virtual:
def __getattr__(self, name):
return lambda obj: getattr(obj, name)()
Keith Dart wrote:
> I guess I just clarify this more. My "unsigned" type really is an object
> that represents a type of number from the external system. Previously,
> there was a nice, clean mapping between external types and Python types.
> Now there is not so clean a mapping. Not that that makes
Florencio Cano Gabarda wrote:
> I would like to do the new SSL module as good as possible. A piece of
> art and efficiency if possible and obviusly having in mind all
> programming standards.
Guido and much of the community would certainly be appreciative of a new
SSL module, especially if you can
Guido van Rossum wrote:
> [Ron Adam]
>
>>with opening(file1,m),opening(file2,m),opening(file3,m) as f1,f2,f3:
>> # do stuff with files
>>
>
> I'm -0 on this, if only because it complicates things a fair bit for a
> very minor improvement in functionality. [...]
> It's always something we can
Greg Ewing wrote:
> Brett C. wrote:
>
>
>>Nick's was obviously directly against looping, but, with no offense to Nick,
>>how many other people were against it looping? It never felt like it was a
>>screaming mass with pitchforks but more of a "I don't love it, but I can deal"
>>crowd.
>
>
> My
Ka-Ping Yee 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):
>>
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
> exceptions that occur into the template generator's inte
Brett C. wrote:
> Guido van Rossum wrote:
>>PEP 340 is still my favorite, but it seems there's too much opposition
>>to it, so I'm trying to explore alternatives; at the same time I
>>*really* dislike the complexities of some of the non-looping
>>counterproposals (e.g. Nick Coghlan's PEP 3XX or the
Guido van Rossum wrote:
> [Nick Coghlan]
>
>>Also, the call to __enter__() needs to be before the try/finally block (as it
>>is
>>in PEP 310). Otherwise we get the "releasing a lock you failed to acquire"
>>problem.
>
>
> I did that on purpose. There's a separate object ('abc' in the
> pseudo-
M.-A. Lemburg wrote:
> It is important to be able to rely on a default that
> is used when no special options are given. The decision
> to use UCS2 or UCS4 is much too important to be
> left to a configure script.
Should the choice be a runtime decision? I think it should be. That
could mean two
Guido van Rossum wrote:
> Going for all-out simplicity, I would like to be able to write these examples:
>
> class locking:
> def __init__(self, lock): self.lock = lock
> def __enter__(self): self.lock.acquire()
> def __exit__(self, *args): self.lock.release()
>
> class opening:
>
Phillip J. Eby wrote:
> FYI, there are still use cases for clearing the exception state in an
> __exit__ method, that might justify allowing a true return from __exit__ to
> suppress the error. e.g.:
Maybe __exit__ could suppress exceptions using a new idiom:
def __exit__(self,*exc):
M.-A. Lemburg wrote:
> All this talk about UTF-16 vs. UCS-2 is not very useful
> and strikes me a purely academic.
>
> The reference to possibly breakage by slicing a Unicode and
> breaking a surrogate pair is valid, the idea of UCS-4 being
> less prone to breakage is a myth:
Fair enough. The or
Martin v. Löwis wrote:
> Shane Hathaway wrote:
>
>>I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
>>widely used and takes less space, while UCS4 is easier to treat as an
>>array of characters. Maybe we can have both: unicode objects start with
>
Martin v. Löwis wrote:
> Shane Hathaway wrote:
>>More generally, how should a non-unicode-expert writing Python extension
>>code find out the minimum they need to know about unicode to use the
>>Python unicode API? The API reference [1] ought to at least have a list
>>
Martin v. Löwis wrote:
> Define correctly. Python, in ucs2 mode, will allow to address individual
> surrogate codes, e.g. in indexing. So you get
>
>
u"\U00012345"[0]
When Python encodes characters internally in UCS-2, I would expect
u"\U00012345" to produce a UnicodeError("character can not
Nicholas Bastin wrote:
>
> On May 6, 2005, at 5:21 PM, Shane Hathaway wrote:
>> Wait... are you saying a Py_UNICODE array contains either UTF-16 or
>> UTF-32 characters, but never UCS-2? That's a big surprise to me. I may
>> need to change my PyXPCOM patch to f
Nicholas Bastin wrote:
> On May 6, 2005, at 3:42 PM, James Y Knight wrote:
>>It means all the string operations treat strings as if they were
>>UCS-2, but that in actuality, they are UTF-16. Same as the case in the
>>windows APIs and Java. That is, all string operations are essentially
>>broken,
Nicholas Bastin wrote:
>
> On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
>> On a related note, it would be help if the documentation provided a
>> little more background on unicode encoding. Specifically, that UCS-2 is
>> not the same as UTF-16, even though they&#x
Just a little offtopic note to Jeff Bone: Jeff, every time I send a
message to Python-Dev, your "Mail.app 2.0" sends me a nasty auto-reply
that I can't quote in public. Please stop. Since I can't seem to reach
you by email, I'm trying to reach you through this mailing list. The
note refers to so
Greg Ewing wrote:
> Shane Hathaway wrote:
>
>>For each block statement, it is necessary to create a *new* iterator,
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
Shane Holloway (IEEE) wrote:
> Another thing. In the specification of the Anonymous Block function, is
> there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"? It
> seems to be a dis-symmetry with the 'for' loop specification.
Hmm... yeah. That's strange. In fact, if it gets chang
Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>
>>"This type represents the storage type which is used by Python
>>internally as the basis for holding Unicode ordinals. Extension module
>>developers should make no assumptions about the size of this type on
>>any given platform."
>
>
> But
Reinhold Birkenfeld wrote:
> Shane Hathaway wrote:
>
>
>>For each block statement, it is necessary to create a *new* iterator,
>
>
> Right.
>
>
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statem
Reinhold Birkenfeld wrote:
> Noam Raphael wrote:
>
>>On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>>resource = opening("file.txt")
>>>resource:
>>>(...)
>>>
>>>The latter would have to be forbidden.
>>
>>Can you explain why it would have to be forbidden please?
>
>
> Well, with
Ka-Ping Yee wrote:
> On Wed, 4 May 2005, Shane Hathaway wrote:
>>
>>for name in filenames:
>>opening(name) as f:
>>if f.read(2) == 0xFEB0:
>>break for
>
>
> This is very elegant.
Thanks.
> It works bea
Shane Hathaway wrote:
> Gustavo J. A. M. Carneiro wrote:
>
>> In PEP 340 I read:
>>
>>block EXPR1 as VAR1:
>>BLOCK1
>>
>> I think it would be much clearer this (plus you save one keyword):
>>
>>block
Gustavo J. A. M. Carneiro wrote:
> In PEP 340 I read:
>
> block EXPR1 as VAR1:
> BLOCK1
>
> I think it would be much clearer this (plus you save one keyword):
>
> block VAR1 = EXPR1:
> BLOCK1
I think you misunderstood the statement. EXPR1 creates an
Alex Martelli wrote:
> Looking for a file with a certain magicnumber in its 1st two bytes...?
>
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
>
> This does seem to make real-life sense to me...
I'd like to suggest a small language enhancement that w
Anders J. Munch wrote:
> in opening('file1') as f1:
> ...
> in opening('file2') as f2:
> ...
> except IOError:
> print "file1 not available, I'll try again later"
>
> I rather like this version, because it is patently clear what should
> happen if there
Luis P Caamano wrote:
> I've been skipping most of the anonymous block discussion and thus,
> I only had a very vague idea of what it was about until I read this
> explanation.
>
> Yes, it is understandable -- assuming it's correct :-)
To my surprise, the explanation is now in the PEP. (Thanks,
Guido van Rossum wrote:
> I don't know. What exactly is the audience supposed to be of this
> high-level statement? It would be pretty darn impossible to explain
> even the for-statement to people who are new to programming, let alone
> generators. And yet explaining the block-statement *must* invo
Michael Chermside wrote:
> if x == 1:|if condition_1:
> do_1() |y = 1
> elif x == 2: |elif condition_2:
> do_2() |y = 2
> elif x == 3: |elif condition_3:
> do_3() |y = 3
> else:
Bob Ippolito wrote:
> The zipfile module is good enough to create input files for zipimport..
> which is well tested and generally works -- barring the fact that
> zipimport has quite a few rough edges of its own. I certainly wouldn't
> recommend it for any heavy duty tasks in its current state.
Robert Brewer wrote:
> I still prefer more methods, because my actual use-cases are more
> complicated. Your solution would work for the specific case I gave, but
> try factoring in:
>
> * A subclass which needs to share locals between begin and post, instead
> of pre and post.
>
> or
>
> * A se
Robert Brewer wrote:
> So currently, all subclasses just override __set__, which leads to a
> *lot* of duplication of code. If I could write the base class' __set__
> to call "macros" like this:
>
> def __set__(self, unit, value):
> self.begin()
> if self.coerce:
>
Michael Chermside wrote:
> In other words, rather than hearing what we'd like to be able to DO
> with blocks, I'd like to hear what we want to PROHIBIT DOING with
> blocks. I think this might be a fruitful way of thinking about the
> problem which might make it easier to evaluate syntax suggestions
Paul Moore wrote:
> I think the key difference with macros is that they act at compile
> time, not at run time. There is no intention here to provide any form
> of compile-time processing, and that makes all the difference.
>
> What I feel is the key concept here is that of "injecting" code into a
Nick Coghlan wrote:
> Which means finding a different name for '__else__'. Two possibilities
> that occur to me are '__ok__' or '__no_except__'. The latter makes a
> fair amount of sense, since I can't think of a way to refer to the thing
> other than as a 'no exception' handler.
While we're on th
Nick Coghlan wrote:
> An alternative would be to replace the 'yield None' with a 'break' or
> 'continue', and create an object which supports the resource protocol
> and NOT the iterator protocol. Something like:
>
> def my_resource():
> print "Hi!" # Do entrance code
> continue # Go on
Fredrik Lundh wrote:
> Brian Sabbey wrote:
>> doFoo(**):
>> def func1(a, b):
>> return a + b
>> def func2(c, d):
>> return c + d
>>
>> That is, a suite can be used to define keyword arguments.
>
>
> umm. isn't that just an incredibly obscure way to write
>
>def func1
68 matches
Mail list logo
