On 21 April 2015 at 11:56, Rob Cliffe wrote:
> On 21/04/2015 10:33, Cory Benfield wrote:
>
> On 21 April 2015 at 10:10, Chris Angelico
> wrote:
>
> At this point, you may want to just stop caring about the exact type.
> Part of the point of gradual typing is that you can short-cut a lot of
>
On 1 May 2015 at 16:31, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel wrote:
>
>> Yury Selivanov schrieb am 30.04.2015 um 03:30:
>> > 1. Terminology:
>> > - *native coroutine* term is used for "async def" functions.
>>
>> When I read "native", I think of native (binary)
Hi, it is not clear whether anything is done to total_cost:
def total_cost(self) -> float:
Does this become a property automatically, or is it still a method call?
To that end, some examples of *using* a data class, not just defining one,
would be helpful.
If it remains a normal method, why
On 12 October 2017 at 11:20, Steve Holden wrote:
> On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller
> wrote:
>
>>
>> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>>
>>> "An object that is not defined by its attributes, but rather by a thread
>>> of continuity and its identity." (from https://en.wik
Big +1 to turning warnings on by default again.
When this behaviour first started, first I was surprised, then annoyed that
warnings were being suppressed. For a few years I learned to have `export
PYTHONWARNINGS=default` in my .bashrc.
But eventually, the warnings in 3rd-party Python modules gr
On 26 April 2018 at 16:18, Chris Angelico wrote:
> On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann
> wrote:
> > Hi list,
> >
> > when reading PEP 572 I actually liked it a lot - I think it's actually
> > a cool idea. I think it's actually that cool an idea that it should be
> > made the defau
On Thu, 14 Jun 2018 at 17:40, Tin Tvrtković wrote:
> Hi,
>
> I've been using asyncio a lot lately and have encountered this problem
> several times. Imagine you want to do a lot of queries against a database,
> spawning 1 tasks in parallel will probably cause a lot of them to fail.
> What you
On Fri, 15 Jun 2018 at 09:18, Michel Desmoulin
wrote:
>
> >
> > The strict API compatibility requirements of core Python stdlib, coupled
> > with the very long feature release life-cycles of Python, make me think
> > this sort of thing perhaps is better built in an utility library on top
> > of a
I think this is a packaging problem.
In an ideal world, Python would ship some version of asyncio, but you would
also be able to pip install a newer version into your virtual environment,
and it would override the version in stdlib.
As it stands now, however, if you pip install another version of
On 28 August 2015 at 17:11, Yury Selivanov wrote:
> On 2015-08-28 11:44 AM, Brett Cannon wrote:
>
>>
>> Unfortunately, separating it from the standard library is something
>> that I don't think we can do so late in the 3.5 release candidates
>> process.
>>
>>
>> Ultimately it's Larry'
On 5 September 2015 at 09:44, haypo s wrote:
> 2015-09-05 5:01 GMT+02:00 Guido van Rossum :
> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> > holiday in the US) in case anything unforeseen comes up, but this is
> really
> > the Last Call for this PEP.
>
> String concat
Why not allow string concatenation without plus sign only if/when the
implementation becomes optimised to allow compile time concatenation? This
makes it crystal clear whether the concatenation is compile time or
runtime. If we allow it now, it's hard to tell without looking at the
CPython source
On 20 September 2015 at 07:55, Nathaniel Smith wrote:
> On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka
> wrote:
> > For now the default value of the stacklevel parameter in warnings.warn()
> is
> > 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> > know cases that n
I tried to reproduce the problem you describe, but failed. Here's my test
program (forgive the awful tab indentation, long story):
--
import asyncio
async def foo():
print("resource acquire")
try:
await asyncio.sleep(100)
finally:
print("resource release")
async def main():
task =
On 15 April 2016 at 18:03, Victor Stinner wrote:
> Hum.
>
> if (width == 0
> and height == 0
> and color == 'red'
> and emphasis == 'strong'
> or highlight > 100):
> raise ValueError("sorry, you lose")
>
> Please remove one space
On 27 January 2014 10:55, Victor Stinner wrote:
> 2014-01-27 Antoine Pitrou :
> > On Mon, 27 Jan 2014 10:45:37 +0100
> > Victor Stinner wrote:
> >>
> >> - Tulip #111: StreamReader.readexactly() now raises an
> >> IncompleteReadError if the
> >> end of stream is reached before we received enough
On 17 February 2014 11:14, M.-A. Lemburg wrote:
> On 15.02.2014 07:03, Stephen J. Turnbull wrote:
> > M.-A. Lemburg writes:
> >
> > > IMO, it was a mistake to have None return a TypeError in
> > > comparisons, since it makes many typical data operations
> > > fail, e.g.
> >
> > I don't underst
On 17 February 2014 11:43, M.-A. Lemburg wrote:
> On 17.02.2014 12:23, Gustavo Carneiro wrote:
> > On 17 February 2014 11:14, M.-A. Lemburg wrote:
> >
> >> On 15.02.2014 07:03, Stephen J. Turnbull wrote:
> >>> M.-A. Lemburg writes:
> >>>
>
On 17 February 2014 12:30, M.-A. Lemburg wrote:
> On 17.02.2014 13:19, Serhiy Storchaka wrote:
> > 17.02.14 13:56, M.-A. Lemburg написав(ла):
> >> Yes, but that's not the point. Unlike strings or other mixed types that
> >> you cannot compare, None is used as placeholder in data processing as
> >
On 12 March 2014 15:21, Brett Cannon wrote:
>
>
>
> On Wed, Mar 12, 2014 at 11:16 AM, Chris Angelico wrote:
>
>> On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon wrote:
>> > While I'm +0 on the idea, I'm -1 on the syntax;
>>
>
> I just don't like having a
>> > colon in an expression.
>>
>
lambda:
On Thu, 5 Jul 2018 at 13:43, Victor Stinner wrote:
> Hi,
>
> My work (*) in the "Assignment expression and coding style: the while
> True case" thread helped me to understand something about the
> *intended* scope.
>
> While technically, assignment expressions keep the same scoping rules
> than a
On Thu, 14 Feb 2019 at 15:52, Victor Stinner wrote:
> Le jeu. 14 févr. 2019 à 14:38, Matthias Klose a écrit :
> > Debian's concern about pointing python to python3 is that it will break
> software
> > after an upgrade. The current state seems is still the same that Debian
> doesn't
> > want to
It's true that asyncio.wait provides the tools that you need, but it's a
bit clunky to use correctly.
Maybe would be something along the lines of:
--
queue1 = asyncio.Queue()
queue2 = asyncio.Queue()
...
get1 = asyncio.create_task(queue1.get())
get2 = asyncio.create_task(queue2.get())
await a
I think using symbols like ? and == in patterns looks stylistically ugly,
and unintuitive, albeit more explicit.
I, too, would rather have pattern matching more explicit, but it shouldn't
need to be so ugly (yes, I know, ugly is a subjective term, so be it).
I would propose that, opposite to what
On Fri, May 31, 2013 at 11:34 AM, Łukasz Langa wrote:
> On 31 maj 2013, at 12:18, Gustavo Carneiro wrote:
>
> > It is not clear from the PEP (up until the end of the User API section
> at least) when, if ever, is this implementation of fun ever called. I
> mean, what type o
Sorry, maybe I am too late to comment on this, but,
>>> @singledispatch
... def fun(arg, verbose=False):
... if verbose:
... print("Let me just say,", end=" ")
... print(arg)
It is not clear from the PEP (up until the end of the User API section at
least) when, if ever,
On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano wrote:
> On 21/06/13 01:35, Benjamin Peterson wrote:
>
>> 2013/6/20 Charles-François Natali :
>>
>>> 2013/6/20 Thomas Wouters :
>>>
If the .py file is going to be wrong or incomplete, why would we want to
keep it -- or use it as fallback -
On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy wrote:
> On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote:
>
>> Hi all, in recent days, there has been a discussion on fedora-devel
>> (see thread [1]) about moving to Python 3 as a default.
>>
>
> Default-shift is a known natural language phenomenon.
> htt
On 10 December 2016 at 13:49, M.-A. Lemburg wrote:
[...]
> Regardless of the name, it'll be interesting to see whether
> there's demand for such a fork. Without a website, binaries
> to download, documentation, etc. it's still in the very early
> stages.
>
IMHO, whether or not there is demand fo
On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote:
[...]
> The question becomes: how to promote the limited C API? Should it
> become the default, rather than an opt-in option?
>
It would be interesting to find out what is the performance impact of using
limited C API, vs normal API, on some
On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote:
> Today I’m happy (and a little trepidatious) to announce the next
> version of PEP 622, Pattern Matching. As authors we welcome Daniel F
> Moisset in our midst. Daniel wrote a lot of the new text in this
> version, which introduces the subject
*facepalm* this is right there in the PEP, already, as one possible
alternative. Apologies for the noise. :-/
On Wed, 8 Jul 2020 at 19:27, Gustavo Carneiro wrote:
>
>
> On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote:
>
>> Today I’m happy (and a little trepidatious) to
On Fri, 10 Jul 2020 at 10:33, Glenn Linderman wrote:
> On 7/10/2020 1:21 AM, Stefano Borini wrote:
> > Just my 2 cents, I find it kind of annoying that the whole structure
> > requires two levels of indentation to actually reach the operational
> > code.
> > This would be a first in python.
> >
>
On Fri, 17 Jul 2020 at 12:26, wrote:
> Hello everyone,
>
> I'm sorry if my proposition has already being said, or even withdrawn,
> but I think that capture variables shouldn't be as implicit as they
> are now. I didn't see any mention of capture variable patterns in
> the rejected ideas. So here
Apologies if this has already been discussed.
I was expecting that by now, python 3.0, the following code:
# clean the target dir
import errno
try:
shutil.rmtree(trace_output_path)
except OSError, ex:
if ex.errno not
(cross-posting back to python-dev to finalize discussions)
2009/4/2 Guido van Rossum
[...]
> > The problem you report:
> >>
> >> try:
> >>...
> >> except OSWinError:
> >>...
> >> except OSLinError:
> >>...
> >>
> >
> > Would be solved if both OSWinError and OSLinError were always
We have to resort to timeouts in pygtk in order to catch unix signals
in threaded mode.
The reason is this. We call gtk_main() (mainloop function) which
blocks forever. Suppose there are threads in the program; then any
thread can receive a signal (e.g. SIGINT). Python catches the signal,
but do
On 9/2/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread; then we can guarantee
> signal handlers are always called from the main thread, and pygtk
> doesn't need a timeout.
1) That page
On 9/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
>
> > According to [1], all python needs to do to avoid this problem is
> > block all signals in all but the main thread;
>
> Argh, no: then people
On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
> > I am now thinking of something along these lines:
> > typedef void (*PyPendingCallNotify)(void *user_data);
> > PyAPI_FUNC(void) Py_AddPen
In GLib we have a child watch notification feature that relies on
the following signal handler:
static void
g_child_watch_signal_handler (int signum)
{
child_watch_count ++;
if (child_watch_init_state == CHILD_WATCH_INITIALIZED_THREADED)
{
write (child_watch_wake_up_pipe[1], "B",
On 9/5/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/4/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > Now, we've had this API for a long time already (at least 2.5
> > years). I'm pretty sure it works well enough on most *nix systems.
> > E
On 9/5/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
[...]
> Even if write is atomic, there are gotchas. What if the interrupted
> code is doing something to that file at the time? Are you SURE that
> an unexpected operation on it (in the same thread) won't cause the
> library function of program
On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> wrote:
> At the risk of waking up a thread that was already declared dead, but
> perhaps this is usefull.
>
> So, what happens is pythons signal handler sets a flag and registrers a
> callback. Then the main thread should check the flag and make the callback
On 9/9/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/8/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Ensuring modifications to that array are atomic would be tricky, but I
> > think it would be doable if we use a read-copy-update approach (with
> > two alternating signal handler functions). Not
On 9/9/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> I was hoping to have stopped, but here are a few comments.
>
> I agree with Jan Kanis. That is the way to tackle this one.
Alas, it doesn't work in practice, as I already replied.
[...]
> Despite the implication, the code of Py_AddPendingCa
On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Now on to my new proposal. I do still use write(). If you can't
> accept that I think we should rip signals out entirely, just let them
> kill the process. Not a reliable feature of any OS.
>
> We create a single pipe and use it for all signals
On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Adam Olsen wrote:
> >
> > > That brings you back to how you access the flags variable.
> >
> > The existing signal handler sets a flag, doesn't it?
> > So it couldn't be any more broken than th
On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/12/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > My previous mention of using a *single* flag may survive corruption
> > > simply bec
On 9/16/06, Talin <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > As for the reason: it makes it possible to use the same style for classes
> > without bases as is used for functions without arguments. Prior to this
> > change, there was a sharp break in the class syntax, such that if you got
int PyErr_CheckSignals()
Documentation for PyErr_CheckSignals [1] says "If an exception is
raised the error indicator is set and the function returns 1;
otherwise the function returns 0.". But the code I see tells me the
function returns -1 on error. What to do? Fix the code, or the
documentati
-> http://www.python.org/sf/1564547
--
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
This patch may interest you: http://www.python.org/sf/1564547
Not sure it completely solves your case, but it's at least close to your
problem.
On 12/4/06, Tony Nelson <[EMAIL PROTECTED]> wrote:
I think I have a need to handle *nix signals through polling in a library.
It looks like chaining
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Ulisses Furquim schrieb:
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix sig
On 2/11/07, Ben North <[EMAIL PROTECTED]> wrote:
Hi,
A few days ago I posted to python-ideas with a suggestion for some new
Python syntax, which would allow easier access to object attributes
where the attribute name is known only at run-time. For example:
setattr(self, method_name, getatt
On 3/11/07, Laurent Gautier <[EMAIL PROTECTED]> wrote:[...]
A prototype is being worked on, and I have been looking at code and/or
functionalities in pydoc, epydoc, pydoctor, and ipython (for the
interactive console), and there a lot of nice things in all these
efforts. The name of the game is n
On 3/21/07, Scott Dial <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:
> A tangential question -- why are TemporaryFile and
> NamedTemporaryFile named in TitleCase, when they're
> functions and not classes?
>
I wondered the same. At first draft of my email I wrote "class"
operating under the assum
On 4/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
[...]
Example
===
This is the standard ``os.path.normpath`` function, converted to type
declaration
syntax::
def normpathƛ(path✎)✎:
"""Normalize path, eliminating double slashes, etc."""
if path✎ == '':
On 4/1/07, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
On 4/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
[...]
> Example
> ===
>
> This is the standard ``os.path.normpath`` function, converted to type
> declaration
> syntax::
>
> def normpathƛ(p
On 29/04/07, James Y Knight <[EMAIL PROTECTED]> wrote:
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote:
> Abstract
>
>
> The PEP defines the proposal to enhance the super builtin to work
> implicitly
> upon the class within which it is used and upon the instance the
> current
> fun
I have to agree with you. If removing support for
self.__dict__['propertyname'] (where propertyname is also the name of a
descriptor) is the price to pay for significant speedup, so be it. People
doing that are asking for trouble anyway!
On 10/06/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
On
While you're at it, it would be nice to fix this ugly asymmetry I found in
descriptors. It seems that descriptor's __get__ is called even when
accessed from a class rather than instance, but __set__ is only invoked from
instances, never from classes:
class Descr(object):
def __get__(self, ob
In PyGObject we want to use a 'message' attribute in an exception defined by
us. The name 'message' comes from a C API, therefore we would like to keep
it for easier mapping between C and Python APIs. Why does Python have to
deprecate this attribute?
.../gobject/option.py:187: DeprecationWarnin
On 08/09/2007, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > Be convoluted yourself and do this:
> >
> > #define PySSL_BEGIN_ALLOW_THREADS { if (_ssl_locks) {
> Py_BEGIN_ALLOW_THREADS
> > #define PySSL_END_ALLOW_THREADS Py_END_ALLOW_THREADS } }
> >
> > (Untested, but I think it should work.)
>
> Ye
On 01/10/2007, Justin Tulloss <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I've been doing some tests on removing the GIL, and it's becoming clear
> that some basic changes to the garbage collector may be needed in order for
> this to happen efficiently. Reference counting as it stands today is not
>
On 02/10/2007, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Justin Tulloss wrote:
> > > Would
> > > somebody care to give me a brief overview on how the current gc module
> > > interacts with the interpreter
> >
> > The cyclic GC kicks in when memo
On 02/10/2007, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct. And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
&g
On 16/11/2007, Benji York <[EMAIL PROTECTED]> wrote:
>
> Gustavo Carneiro wrote:
> > I am finding myself often doing for loops over a subset of a list, like:
> >
> > for r in results:
> > if r.numNodes != numNodes:
> >
I am finding myself often doing for loops over a subset of a list, like:
for r in results:
if r.numNodes != numNodes:
continue
# do something with r
It would be nice if the plain for loop was as flexible as list
comprehensions and allowed an optiona
On 07/12/2007, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote:
> >That's pretty much what issue1564547 does. I think there's two marks
>
> Good point, I hadn't seen that before.
>
> >* Using poll and fd's is pretty platform specific for
On 08/12/2007, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Adam, perhaps at some point (Monday?) we could get together on
> > #python-dev and interact in real time on this issue. Probably even
> > better on the phone. This offer is open to anyone who is serious about
> >
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > Not only that, but pygtk is a generic module;
>
> What does "generic" mean in this context? Surely not that it appli
signal check in the
> > VM main loop but before the select()/poll() system call is entered
> > will not be noticed until the select()/poll() call completes).
>
> Sorry, I misattributed this; Gustavo Carneiro pointed this out earlier
> in this thread.
>
> BTW, in the refer
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMA
On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > On Dec 8, 2007 2
On 10/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > Adam & I are now on #python-dev. Can you join?
>
> I think we successfully resolved this. Adam Olsen will produce a patch
> that allows one to specify a single file descriptor to which a zero
> byte will be written by the C-level sign
On 11/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2007 4:07 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 10/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > > Adam & I are now on #python-dev. Can yo
On 17/04/2008, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> shutil.copytree is very convenient to make recursive copies, but
> os.walk has to be used everytime some filtering
> has to be done on the files copied., if you want to avoid copying some
> files.
>
> The code pattern with os.walk is
2008/5/1 Facundo Batista <[EMAIL PROTECTED]>:
> 2008/5/1, Georg Brandl <[EMAIL PROTECTED]>:
>
> > There may be more implications and surprising behavior surrounding
> this.
> >
> > I know that the implementation is a compromise, but I'd rather see a
> > super()
> > whose full semantics can be
2008/11/28 Hrvoje Niksic <[EMAIL PROTECTED]>
> A friend pointed out that running python under valgrind (simply "valgrind
> python") produces a lot of "invalid read" errors. Reading up on
> Misc/README.valgrind only seems to describe why "uninitialized reads" should
> occur, not invalid ones. For
2009/1/19 Vitor Bosshard
>
>
>
>
> - Mensaje original
> > De: Gerald Britton
> > Para: Terry Reedy
> > CC: python-dev@python.org
> > Enviado: lunes, 19 de enero, 2009 15:03:47
> > Asunto: Re: [Python-Dev] PEP 3142: Add a "while" clause to generator
> expressions
> >
> > Duly noted and
On 3/29/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:>For Zope 3, we have decorators that work with the component architecture (I'm>sure Phillip is familiar with these). They're used with functions to>indicate that the function adapts a partic
why include Construct?* the struct module is very nice, but very limited and non-pythonic as well
* pure python (no platform/security issues) IMHO this is a drawback. More on this below.
* lots of people need to parse and build binary data structures, it's not an esoteric library
* license: publi
on-foo-bar, while they're not really related.
I hope I made the problem clear enough, and I hope people find this a compelling argument in favour of eliminating the need for __init__.py. Regards,Gustavo Carneiro.
___
Python-Dev mailing list
Python
On 4/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:>> > Now the problem. Suppose you have the source package python-foo-bar,
> > which installs $pyth
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 4/27/06, Gustavo Carneiro <
[EMAIL PROTECTED]> wrote:
On 4/27/06, Phillip J. Eby <
[EMAIL PROTECTED]> wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTE
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 4/27/06, Gustavo Carneiro <
[EMAIL PROTECTED]> wrote:
Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages.
It *is* a solution for my
On 5/3/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
[Crossposting to both python-dev and ctypes-users, please respond to the listthat seems most appropriate]Guido van Rossum wrote:> File "/home/guido/projects/python/trunk/Lib/ctypes/__init__.py",
> line 288, in __init__> self._handle = _dlope
Sorry this is slightly offtopic, but I think it's important...
According to recent experiments tracking down a memory leak, it
seems that PyObject_CallFunction(func, "N", object) and
PyObject_CallFunction(func, "O", object) are doing exactly the same
thing. However, documentation says "The C
On 6/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Gustavo Carneiro wrote:
> > However, PyObject_CallFunction does _not_
> > consume such an object reference, contrary to what I believed for
> > years.
>
> Why do you say that? It certainly doe
91 matches
Mail list logo
