Chris Lambacher schrieb:
> I think a better question is what about Distutils hinders cross-compiler
> scenarios and how to we fix those deficiencies?
It's primarily the lack of contributions. Somebody would have to define
a cross-compilation scenario (where "use Cygwin on Linux" is one that
might
David Boddie schrieb:
> It seems that Martin's patch solves some problems I encountered more cleanly
> (in certain respects) than the solutions I came up with. Here are some
> issues I encountered (from memory):
Just let me point out that it is not my patch:
http://python.org/sf/841454
was contr
[EMAIL PROTECTED] schrieb:
> Someone (I don't know who) submitted a patch to use SCons for building
> modules in cross-compilation contexts. Either the author tried to shoehorn
> this into distutils and failed or never tried (maybe because using SCons for
> such takss is much easier - who knows?).
Patch #1067760 deals with passing of float values to file.seek;
the original version tries to fix the current implementation
by converting floats to long long, rather than plain C long
(thus supporting files larger than 2GiB).
I propose a different approach: passing floats to seek should
be an err
Fredrik Lundh schrieb:
> I guess I should remember, but what's the rationale for not including
> even a single concrete "tzinfo" implementation in the standard library?
>
> not even a UTC class?
>
> or am I missing something?
If you are asking for a time-zone database, such as pytz
(http://sour
I'd like to share an observation on portability of extension
modules to Python 2.5: python-ldap would crash on Solaris, see
http://groups.google.com/group/comp.lang.python/msg/a678a969c90f21ab?dmode=source&hl=en
It turns out that this was caused by a mismatch in malloc
"families" (PyMem_Del vs. P
Patch #849407 proposes to change the meaning of the
urllib reporthook so that it takes the amount of the
data read instead of the block size as its second
argument.
While this is a behavior change (and even for
explicitly-documented behavior), I still propose
to apply the change:
- in many cases,
Nick Coghlan schrieb:
> Martin v. Löwis wrote:
>> I personally consider it "good style" to rely on implementation details
>> of CPython;
>
> Is there a 'do not' missing somewhere in there?
No - I really mean it. I can find nothing wrong with people rel
Thomas Heller schrieb:
> What should we do now? Should the conditional be changed to
>
> #if defined(__ppc__) || defined(_POWER)
>
This would be the right test, if you want to test for "power-pc
like". POWER and PowerPC are different processor architectures,
IBM pSeries machines (now System p)
tomer filiba schrieb:
> okay, that would suffice. but why isn't it part of stdlib already?
> the pep is three years old... it should either be rejected or accepted.
> meanwhile, there are lots of missing API functions in the floating-point
> implementation...
It's not rejected because people keep
Ian Murdock schrieb:
> I'm CTO of the Free Standards Group and chair of the Linux Standard
> Base (LSB), the interoperability standard for the Linux distributions.
> We're wanting to add Python to the next version of the LSB (LSB 3.2) [1]
> and are looking for someone (or, better, a few folks) in t
Talin schrieb:
> As far as rewriting it goes - I can only rewrite things that I understand.
So if you want this to change, you obviously need to understand the
entire distutils. It's possible to do that; some people have done
it (the "understanding" part) - just go ahead and start reading source
c
Phillip J. Eby schrieb:
> Actually, I meant that (among other things) it should be clarified that
> it's alright to e.g. put .pyc and data files inside Python library
> directories, and NOT okay to split them up.
My gut feeling is that this is out of scope for the LSB. The LSB would
only specify
Jan Matejek schrieb:
> +1 on that. There should be a clear (and clearly presented) idea of how
> Python is supposed to be laid out in the distribution-provided /usr
> hierarchy. And it would be nice if this idea complied to FHS.
The LSB refers to the FHS, so it is clear that LSB support for Python
Talin schrieb:
> To that extent, it can be useful sometimes to have someone who is in the
> process of learning how to use the system, and who is willing to
> carefully analyze and write down their own experiences while doing so.
I readily agree that the documentation can be improved, and appla
Robin Bryce schrieb:
> python2.4 profile (pstats) etc, was removed due to licensing issues
> rather than FHS. Should not be an issue for python2.5 but what, in
> general, can a vendor do except break python if their licensing policy
> cant accommodate all of pythons batteries ?
If some vendor has
Guido van Rossum schrieb:
> I wonder if would help if we were to add a vendor-packages directory
> where distros can put their own selection of 3rd party stuff they
> depend on, to be searched before site-packages, and a command-line
> switch that ignores site-package but still searches vendor-pack
Robin Bryce schrieb:
> Yes, especially with the regard to the level you pitch for LSB. I
> would go as far as to say that if this "contract in spirit" is broken
> by vendor repackaging they should:
> * Call the binaries something else because it is NOT python any more.
> * Setup the installation
Jan Claeys schrieb:
> Like I said, it's possible to split Python without making things
> complicated for newbies.
You may have that said, but I don't believe its truth. For example,
most distributions won't include Tkinter in the "standard" Python
installation: Tkinter depends on _tkinter depends
Fredrik Lundh schrieb:
> maybe we could just ask distributors to prepare a page that describes
> what portions of the standard distribution they do include, and in what
> packages they've put the various components, and link to those from the
> library reference and/or the wiki or FAQ? is there
Ben Wing schrieb:
> i'd much rather see something like:
>
> for x:iter in list:
> ...do something...
> if x should be deleted:
> iter.delete()
You can easily implement that feature yourself if you need it,
at least for lists (or sequences that support integer indexing):
class deletable_i
Ben Wing schrieb:
> this one is fairly simple. if `m' is a match object, i'd like to be
> able to write m[1] instead of m.group(1). (similarly, m[:] should return
> the same as list(m.groups()).) this would remove some of the verbosity
> of regexp code, with probably a net gain in readability; cer
Fredrik Lundh schrieb:
> the most important issue is that if you want an object to behave as a
> sequence of something, you need to decide what that something is before
> you start tinkering with the syntax.
>
> under Ben's simple proposal, m[:][1] and m[1] would be two different
> things. I'm
Barry Warsaw schrieb:
>> Several issues need to be taken into account:
>> - documentation and test cases must be updated to integrate the new API
>> - for slicing, you need to consider not only omitted indices, but also
>> "true" slices (e.g. m[1:5])
>> - how should you deal with negative indices
Aahz schrieb:
>>> this one is fairly simple. if `m' is a match object, i'd like to be
>>> able to write m[1] instead of m.group(1). (similarly, m[:] should return
>>> the same as list(m.groups()).) this would remove some of the verbosity
>>> of regexp code, with probably a net gain in readability;
Armin Rigo schrieb:
> Ah, distutils are distributed in the base package now, but not the
> 'config' subdirectory of a standard library's normal installation, which
> makes distutils a bit useless.
>
> I should go and file a bug, I guess. The reason why I did not do it so
> far, is that the fact t
Fredrik Lundh schrieb:
>> Ah, right; I misread his proposal as saying that m[:] should return
>> [m[0]] + list(m.groups()) (rather, I expected that m.groups() would
>> include m.group(0)).
>
> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
> RE syntax (and we don't have
Fredrik Lundh schrieb:
>>> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
>>> RE syntax (and we don't have much control over the latter).
>> py> m = re.match("a(b)","ab")
>> py> m.group(0)
>> 'ab'
>> py> m.group(1)
>> 'b'
>
> 0 isn't a group, it's an alias for the full m
Steve Holden schrieb:
> Precisely. But your example had only one group "(b)" in it, which is
> retrieved using m.group(1). So the subgroups are numbered starting from
> 1 and subgroup 0 is a special case which returns the whole match.
>
> I know what the Zen says about special cases, but in this c
Fredrik Lundh schrieb:
> it can quickly become rather confusing if you also interpret m[:] as
> m.groups(), not to mention if you add len() and arbitrary slicing to
> the mix. what about m[] and m[i,j,k], btw?
I take it that you are objecting to that feature, then?
Regards,
Martin
_
Brian Harring schrieb:
> For dict; it actually *cannot* work. You can't remove keys from a
> dict as you're iterating over it (can change the val of a key, but not
> remove the key).
I think this is incorrect. The implementation could well support it,
putting a dummy object into the deleted key
Ben Wing schrieb:
> i do see your point. i was trying to remember what i ended up doing
> when i ran into this issue before, and in fact i ended up just making a
> new list and appending all the elements i didn't want to delete. i see
> you'd get N^2 behavior if you deleted lots of elements fr
Hasan Diwan schrieb:
> The attached patch ensures that the $(DESTDIR) exists before
> installing the built binaries. It has been tested on Mac OS X. The
> patch is attached.
Please post patches to sf.net/projects/python
Thanks,
Martin
___
Python-Dev mai
We just had (the first day of) an LSB face-to-face meeting
today [1], where Python was discussed. I started with presenting
my slides, and stated what I see as main goals:
- Allow Python scripts to run unmodified across Linux distributions
- Optional: Allow extension modules to be used in binary f
Some people (Robert Schweikert) requested byte-code stability at the
LSB meeting: LSB should standardize a certain version of the byte code,
and then future versions of Python should continue to support this
byte code version.
I explained that this is currently not supported, but would be
technica
At the LSB meeting, there was a brief discussion of what Python
version should be incorporated into LSB. This is more an issue
if ABI compatibility for the C ABI is desired, but even if only
script portability is a goal, application developers will need
to know what APIs they have available in LSB
At the LSB meeting, Jeff Licquia asked whether Python could provide
binary compatibility with previous versions by use of ELF symbol
versioning. In ELF symbol versioning, you can have multiple
definitions for the same symbol; clients (e.g. extension modules)
would refer to a specific version. Durin
Brett Cannon schrieb:
> Some people (Robert Schweikert) requested byte-code stability at the
> LSB meeting: LSB should standardize a certain version of the byte code,
> and then future versions of Python should continue to support this
> byte code version.
>
>
> Did they say why
> [private, but feel free to respond on-list]
>> - Allow Python scripts to run unmodified across Linux distributions
>> - Optional: Allow extension modules to be used in binary form across
>> distributions
>> - Optional: Allow extension modules to be used in binary form across
>> distributions
Brian Harring schrieb:
>> I think this is incorrect. The implementation could well support it,
>> putting a dummy object into the deleted key (which deletion needs
>> to do, anyway).
>
> The implementation already uses a sentinel (NULL)-
That' not the full truth. The implementation has a separate
Neal Norwitz schrieb:
> What, if any, impact do you think the LSB should have wrt maintaining 2.4?
People at the meeting specifically said whether security patches would
still be applied to older releases, and for how many older releases.
Linux distributors are hesitant to make commitments to main
Neal Norwitz schrieb:
>> All in all, I think providing binary compatibility would
>> be feasible, and should be attempted. What do you think?
>
> Let's assume that 2.4 is the first LSB version. The ABI is different
> for 2.4 and 2.5. We can't change the ABI for 2.5 since it's already
> released
Anthony Baxter schrieb:
>> So I think a public statement that we will support 2.4 with
>> security patches for a while longer (and perhaps with security
>> patches *only*) would be a good thing - independent of the LSB,
>> actually.
>
> Well, I don't know what sort of public statement you want to
[EMAIL PROTECTED] schrieb:
> >> All in all, I think providing binary compatibility would be feasible,
> >> and should be attempted. What do you think?
>
> Neal> Let's assume that 2.4 is the first LSB version. The ABI is
> Neal> different for 2.4 and 2.5. We can't change the ABI f
Han-Wen Nienhuys schrieb:
> In response to Martin v Loewis' initial reply we have sent in
> contributor agreements, but nothing else has happened so far.
>
> I was wondering whether there is any way for me to speed up the review
> process.
It may not be what you expect to hear, but there actually
[EMAIL PROTECTED] schrieb:
> Taking one example from this thread, Python's bytecode has always been an
> internal implementation detail.
I think that has stopped being true at least since I wrote 1997, or
perhaps even since dis.py was written (i.e. right from the beginning
of the language). With d
In bug #1566280 somebody reported that he gets an
exception where the logging module tries to write
to closed file descriptor.
Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the program is far from exiting a
Neal Norwitz schrieb:
> I think we should document our intentions in the release PEP (or some
> other PEP possibly). Should we state that we will support version x.y
> for N years after initial release or based on version numbers such as
> x.(y-N) where y is the current version and N is a small nu
Tim Peters schrieb:
>> Upon investigation, it turns out that the file descriptor
>> is closed because the logging atexit handler is invoked.
>> This is surprising, as the program is far from exiting at
>> this point.
>
> But the main thread is done, right?
Wrong. main.py (which is the __main__ sc
Greg Ewing schrieb:
> Could backwards compatibility concerns be addressed
> by including more than one version of Python in
> the LSB? Python already allows multiple versions
> to coexist, so applications targeting the LSB
> would just need to be explicit about which version
> of the interpreter to
Tim Peters schrieb:
> Sorry, I couldn't follow the intent there. Not obvious to me how
> moving this stuff from `threading` into `thread` would make it
> easier(?) for the implementation to wait for non-daemon threads to
> finish.
Currently, if you create a thread through the thread module
(rathe
Alastair Houghton schrieb:
> How about we remove the word "foolish" from the debate?
We should table the debate. If you really want that feature,
write a PEP. You want it, some people are opposed; a PEP is
the procedure to settle the difference.
Regards,
Martin
___
#1610575 suggests to introduce the 't' code to support the _Bool
type where available, and uses char if it isn't available.
Any objections to adding it?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Guido van Rossum schrieb:
> I looked through the python.org web stats (as I usually do when
> preparing for a keynote) and discovered that
> /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971
> hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz
> (47,898 hits). Are th
Terry Reedy schrieb:
> How do the first two months downloads of 2.5.msi compare to 2.4.msi?
It's actually publicly available:
http://www.python.org/webstats/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Thomas Heller schrieb:
> Also interesting are the hits for 64-bit windows Pythons:
>
> /ftp/python/2.5/python-2.5.amd64.msi (23192 hits)
> /ftp/python/2.5/python-2.5.ia64.msi (22523 hits)
But maybe misleading, as well. People just don't understand Win64:
the hardware guy told them they have "64-b
Martin v. Löwis schrieb:
>> Have the ratios changed against past figures (too lazy to look them up now)?
>
> They did, but also because the statistics weren't updated correctly
> until recently.
Qualifying a bit further: the last month that apparently had nearly
corre
Albert Strasheim schrieb:
> I'm only guessing here, but I think the Windows SDK is probably going to
> become the de facto standard for building software on Windows in the absence
> of Visual Studio. Has anybody else looked at the Windows SDK yet? Any
> thoughts on what needs to be done with dis
Anthony Roy schrieb:
> Any thought?
In addition to what Brett said: please make functionality changes and
refactoring separate patches (specify the order of application if
one depends on the other).
When reading commit message, or performing "svn blame", it's important
to know whether a change is
Daniel Watkins schrieb:
> I've just been putting together a podcasting doodad and have included
> resuming
> support in it. Is this something that's already in the pipeline or should I
> abstract it out to urllib and submit a patch?
Not sure where you got the impression that 206 is "resume"; in
Fredrik Lundh schrieb:
> given that urllib2 already supports partial requests, I'm not sure I see
> the point of reimplementing this on top of httplib. an example:
>
>import urllib2
>
>request = urllib2.Request("http://www.pythonware.com/daily/index.htm";)
>request.add_header("range
Oleg Broytmann schrieb:
>IMO you better don't because urllib2 provides not only an abstraction,
> but a lot of services (authenticated proxies, cached FTP files)...
If you are using http ranges, cached FTP files won't do any good.
As for authenticated proxies: I think they ought to be implemen
Oleg Broytmann schrieb:
>HTTP is one of the most widely known and used protocol. Would you better
> have big httplib and small abstract urllib? so abstract it doesn't allow a
> user to change protocol-specific handling?
Personally, I think very elaborate support for HTTP in httplib, and very
f
Andrea Griffini schrieb:
> My opinion is that it would be by far better to do this ordering
> of co_names at compile time but I've no idea where to look
> for trying to make such a change.
>
> Can someone please point me in the right direction ?
It's all in Python/compiler.c. The names list is cr
Raymond Hettinger schrieb:
> If you can find some other design that doesn't depend on the ordering of
> co_names, that would be nice; otherwise, we're adding a permanent
> complication to the compiler and establishing a new invariant that would
> have to be maintained by everyone hoping to generate
tomer filiba schrieb:
> my question is, how come classes don't create cell variables, like
> normal functions?
Not sure what you mean by "how come"? Why is the implementation
reacting as it is? Because the body of class is compiled as
a global code fragment, not as a nested one.
Or why is the imp
A.M. Kuchling schrieb:
> The constants were added in 2.5. I've gone ahead and made the
> documentation change to trunk and 25-maint, because why were the
> constants added if they weren't intended to be used?
See #711830. They were added for compatibility (with earlier Python
releases) primarily.
Fred L. Drake, Jr. schrieb:
> Speaking strictly for myself: I don't think I *have* to use them, but I do
> prefer to use them because I don't like magic constants that affect what a
> function does in code; I'd rather have a named constant for readability's
> sake. Maybe I just can't keep enou
Jeremy Kloth schrieb:
> 1) is subclassing Python classes in C as a static type supported? Even if
> they
> would be declared on the heap, they would be bound to the first loaded Python
> class.
As you found out: no, this isn't supported.
To work around, you can wrap the extension module with P
Jeremy Kloth schrieb:
>> I think you understand exactly what is happening. It is happening for
>> good reasons. Rather than asking for a change in semantics, I
>> recommend that you deal with it, either in your Python code, or in
>> your extension. It's not likely to change.
>
> I don't believe I
Brett Cannon schrieb:
> I originally posted this list to python-3000 since I figured we could
> be more aggressive with Py3K, but Guido said I should move it over
> here and just be aggressive in 2.6.
Please follow PEP 11 in doing so. This means you cannot remove the code
in Python 2.6, only break
Brett Cannon schrieb:
> > * AtheOS
> > * BeOS
>
> In both cases, the last maintainer should be contacted before the
> platform is unsupported.
>
>
> I guess I can go off the emails listed in README and Misc/BeOS-NOTES,
> although I would hope that any maintainer would watch pytho
Evgeniy Khramtsov schrieb:
> Is there any plans to implement non-blocking timer like a
> threading.Timer() but without thread?
On Unix, you can use signal.alarm.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
In #1626545, Anton Tropashko requests that object.h should be
renamed, because it causes conflicts with other software.
I would like to comply with this requests for 2.6, assuming there
shouldn't be many problems with existing software as object.h
shouldn't be included directly, anyway.
What do y
Guido van Rossum schrieb:
> Maybe this should be done in a more systematic fashion? E.g. by giving
> all "internal" header files a "py_" prefix?
Yet another alternative would be to move all such header files into a
py/ directory, so you would refer to them as
#include "py/object.h"
Any preferenc
Thomas Wouters schrieb:
> (Only for header
> files that should really be internal, of course, not ones that are
> oft-used outside the core.)
Which are these?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Neal Norwitz schrieb:
> Wow, I didn't realize I was that much of a broken record. :-)
> I don't even remember talking to Thomas about it, only Guido. I
> definitely would like to see all private header files clearly denoted
> by their name or directory.
What is a private header file, and does Pyt
Neal Norwitz schrieb:
> By private, I mean internal only to python and don't need to prefix
> their identifiers with Py and are subject to change without backwards
> compatibility. Include/graminit.h is one example of what I mean.
> Some others are: bitset.h, grammar.h, opcode.h, metagrammar.h,
>
Neal Norwitz schrieb:
> I'm a Python embedder and I want to know what's available to me. I
> look in Include and see a ton of header files. Do I need all these?
> What do I *need* and what can I *use*? I only want to see the public
> stuff that is available to me. Thus I want anything that has
Barry Warsaw schrieb:
> I agree. I don't mind if Python.h is just a wrapper around #includes
> from python/*.h. I think we should add structmember.h and structseq.h
> to Python.h and perhaps move everything else into a 'python' subdirectory.
For the python subdirectory, there is the issue that t
Andrea Griffini schrieb:
> I've a partially related question... why isn't the module structure in
> an include file .h
> and is instead in Objects/moduleobject.c ?
> For the cached lookup optimization I copied the definition but that's surely
> a bad way to do it I however wondered if there we
Christos Georgiou schrieb:
> Is that intentional?
It would have helped if you had said what "that" is you are referring
to, it would also have helped if you had stated an opinion on whether
you believe that to be a bug. For example, I think I would have phrased
your post like this:
"""
If I apply
Georg Brandl schrieb:
>> If Python 3.0 was simply a release which removed deprecated features,
>> there would clearly be no issue. I would update my code in advance of
>> the 3.0 release to not use any of those features being removed, and
>> I'm all set. But that's not what I'm hearing. Pytho
Anthony Baxter schrieb:
> There's a couple of ways I see it - we could add a "-3" command line
> flag to enable 3.x compat, or maybe a from __future__ statement.
> Although the latter would be a global thing, which is different to
> how all existing from __future__s work, so probably not good.
[EMAIL PROTECTED] schrieb:
> It would certainly be possible to have:
>
>from __future__ import items_is_iter
>
> be the same as:
>
>__py3k_compat_items_is_iter__ = True
>
> and have the 2.x series' items() method check the globals() of the
> calling scope to identify the return value o
[EMAIL PROTECTED] schrieb:
>>There will certainly be demand for an asynchronous server in 3.0,
>
> To flip the question around: there might be a demand for Twisted in 3.0,
> but will there be a demand for 3.0 in Twisted? It might just be easier
> for everyone concerned to just continue maintainin
Emerson Clarke schrieb:
> Add this to the Read() method before reading takes place:
If you don't submit it as a patch to sf.net/projects/python, it
is likely to get ignored.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Sean Reifschneider schrieb:
> In general I'm reluctant to suggest a Python fix to this, but it's fairly
> unexpected for time.sleep() to raise an exception...
>
> Thoughts?
Unless there is a reproducible test case, no action should be taken.
Once there is a test case, the specific action to take
> Why do you think that this would be that certainly possible?
> I cannot imagine an efficient implementation.
>
>
> Ah, but can you imagine an inefficient one?
I think so (although one can never know until it's implemented).
> If so, we're no longer
> arguing about whether it's possib
[EMAIL PROTECTED] schrieb:
> Also, the exact strategy I suggested could be implemented in various
> ways that might be efficient. Here are a few ways it might be made more
> efficient than the straw many of one extra dict lookup per call to
> keys() et. al.:
I'm not saying that an efficient imple
A.M. Kuchling schrieb:
> What about turning all references to obj.items into the equivalent
> bytecode for this:
>
> if isinstance(obj, dict): # XXX should this be 'type(obj) is dict'?
>if <2.x behaviour>: _temp = obj.items
>elif <3.x behaviour>: _temp = obj.iteritems
> else:
>_temp
Neal Norwitz schrieb:
> http://python.org/sf/1637022 points out a problem caused by the lack
> of a _Py prefix on Ellipsis. Most (all?) of the new AST names are not
> prefixed. These are all meant to be internal names. Are there any
> issues with changing this? If we do so, it means that any mo
Larry Hastings schrieb:
> I just ran a quickie experiment and determined: when leaving a scope,
> variables are deleted FIFO, aka in the same order they were created.
Your experiment was apparently incomplete: Variables are *not* deleted
in the same order in which they are created:
py> class A:
Brett Cannon schrieb:
> Anybody have any ideas on how to deal with this short of rewriting
> some codecs stuff so that they don't depend on global state in the
> module or just telling me to just live with it?
There is an old patch by Armin Rigo ( python.org/sf/812369 ), which
attempts to implemen
Josiah Carlson schrieb:
> Seems to me like a bug, but the bug could be fixed if the module's
> dictionary kept a (circular) reference to the module object. Who else
> has been waiting for a __module__ attribute?
This is the time machine at work:
py> import encodings
py> encodings.search_function
Josiah Carlson schrieb:
> I was saying that it would be nice if the following were true:
>
> >>> encodings.__module__
>
Ah, ok. It would be somewhat confusing, though, that __module__ is
sometimes a module object, and sometimes a string (it certainly confused
me).
> So what if it is a c
Bug #1579370 reports a crash when accessing the thread state of
a terminated thread, when releasing a generator object.
In analysing the problem, I found that f_tstate doesn't have much
utility: it is used in very few places, and in these places, it
might be as good or better to use the *current*
Georg Brandl schrieb:
> Do I miss something here, or is the buildbot hit by spammers now?
It looks like it is. If that continues, we have to disable the web
triggers.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Kristján V. Jónsson schrieb:
> I am trying to insert a hook into python enabling a callback for all
> just-created objects. The intention is to debug and find memory leaks,
> e.g. by having the hook function insert the object into a WeakKeyDictionary.
I'd like to point out that this isn't a pytho
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't know what is the current plan for signals support in pyth
1801 - 1900 of 5277 matches
Mail list logo
