On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby wrote:
> names for the same thing. (I'm guessing that PIL was registered on PyPI
> manually, before the "setup.py register" command existed. Heck, it was
> probably being distributed before the distutils even existed, and indeed
> before there were such
d stuff *before* they did that. That *is* a community problem.
(Luckily, there are people helping out, and the "nice people
driven-development" rule overrides that other rule I mentioned, so
things will get tweaked sooner or later.)
On Mon, Oct 5, 2009 at 1:02 PM, Nick Coghlan wro
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh wrote:
> it's reviews like this that makes me wonder if releasing open source is
> a good idea:
>
> no egg - worst seen ever, remov
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> While I have your attention, please also review
>
> http://bugs.python.org/issue6233
I'm pretty sure that fix is the wrong fix - afaik, _encode is used to
encode tag/attribute names, and charrefs don't work in that context.
___
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> Fredrik Lundh wrote:
>>> I think you really need to get Fredrik Lundh to comment on it. If he
>>> can't predict when he'll be able to review the changes, maybe he can
>>> accept releasin
2009/6/20 "Martin v. Löwis" :
>> I‘d really like to get this stuff in. The performance gains allowing
>> http1.1 and gzip for xmlrpc are quite significant.
>
> I think you really need to get Fredrik Lundh to comment on it. If he
> can't predict when he'l
http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/
mentions that Objects/frameobject.c contains a C99-style comment, which
means that Python 2.6 won't build on AIX.
shouldn't we use a suitable gcc option for the buildbots to prevent that
from happening?
_
Brett Cannon wrote:
You sit in front of a bunch of people answering questions asked by the
audience. You know, a panel. =) It's just a Q&A session so that PyCon
attendees can ask python-dev a bunch of random questions. Demystifies
some things and puts faces to python-dev.
and using moderator.a
the "Code Migration and Modernization" PEP hasn't been updated for 2.5
and 2.6.
http://www.python.org/dev/peps/pep-0290/
surely there's something new in 2.5 and 2.6 that might be worth mentioning?
___
Python-Dev mailing list
Python-Dev@python.o
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in (self.db, self.db.keys())
which is very different from the actual meaning,
a
Olemis Lang wrote:
Fetching external item into 'docutils'
svn: Can't connect to host 'svn.berlios.de': A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond.
> Pleas
Barry Warsaw wrote:
(I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but
have had absolutely no time to spend on that. is the window still open?)
There are 8 open release blockers, a few of which have patches that need
review. So I think we are still not ready to release rc1.
Barry Warsaw wrote:
I'm not going to release rc1 tonight. There are too many open release
blockers that I don't want to defer, and I'd like the buildbots to churn
through the bsddb removal on all platforms.
I'd like to try again on Friday and stick to rc2 on the 17th.
any news on this fro
Terry Reedy wrote:
In particular, built-in functions, in spite of of being labeled
'builtin_function_or_method', are not usable as methods because they
lack the __get__ method needed to bind function to instance.
They're not usable as Python-level instance methods, but they're
definitely usa
Antoine Pitrou wrote:
event_class = Event().__class__ ?
Not pretty I know :-)
somewhat prettier, assuming 2.3 or newer:
>>> import threading
>>> e = threading.Event()
>>> type(e)
>>> isinstance(e, type(threading.Event()))
True
(but pretty OT)
Benjamin Peterson wrote:
Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)
the threading "non-classes" are documented to be factory functions on
the module page.
___
Fredrik Lundh wrote:
(using 3.0a4)
ahem. I could have sworn that I installed a beta, but I guess the
Windows builds weren't fully synchronized when I did that. I still get
the same error after updating to 3.0b2, though.
(the download page still says "This is an alpha rel
(using 3.0a4)
>>> exec(open("file.py"))
Traceback (most recent call last):
File "", line 1, in
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
so what's "file" referring to here?
(the above works under 2.5, of course)
___
Curt Hagenlocher wrote:
I've found the documentation for CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty
reliable. And the mention of a ".com" in the docs suggests that the
description has been around for a while...
And I just described it as pretty vague ;-
Guido van Rossum wrote:
I can't reproduce this as described.
Which Windows version? This sounds like one of those things that could
well vary by Windows version; if it works for you in Vista it may well
be broken in XP. It could also vary by other setup parameters besides
PATHEXT.
It works t
Kilian Klimek wrote:
Saying "your method must accept an extra parameter (which most people
call 'self') that carries all object attributes" is hardly any more
explicit then saying "there is a special variable (which is always named
'this') that carries all object attributes".
in this context
Barry Warsaw wrote:
You don't mean the experts claimed they weren't important, right?
Unimportant changes definitely don't need to go in now .
Well, at least Guido managed to figure out what I was trying to say ;-)
___
Python-Dev mailing list
Pyt
Barry Warsaw wrote:
I agree. This seriously feels like new, potentially high risk code to
be adding this late in the game. The BDFL can always override, but
unless someone is really convincing that this is low risk high benefit,
I'd vote no for 2.6/3.0.
at least two Unicode experts have st
Thomas Heller wrote:
I'm beginning to suspect that I have a botched VS install on this
machine, though. I'll investigate.
Do you get a traceback when you set the DISTUTILS_DEBUG environment
> variable?
Indeed I do:
...
File "c:\python26\lib\distutils\msvc9compiler.py", line 436, in com
Amaury Forgeot d'Arc wrote:
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve setupt
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve setuptools (and none of
the hits
>Isaac Morland wrote:
This would avoid accidentally leaving out commas in list construction,
but tuple construction would still have the same problem.
Tuple construction already has a "no comma, no tuple" problem. That
problem remains, but as soon as you add a comma, you'll get the same
pro
Tres Seaver wrote:
- -1. The feature exists to allow adherence to PEP-8, "Limit all lines to
a maximum of 79 characters.", without requiring runtime concatenation
costs. I use it frequently when assembling and testing message strings,
for instance.
removing it is a bad idea for the reasons a
when did Python-Dev turn into a members only list, btw?
---
Your mail to 'Python-Dev' with the subject
Re: Unicode 5.1.0
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
---
___
On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> (how's the 3.2/4.1 dual support implemented? do we have two distinct
>> datasets, or are the differences encoded in some clever way? would it
>> make sense to split the unicodedata module into three separate
>> modul
On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> So while we could say: "we provide access to the Unicode 5.1.0
>> database", we cannot say: "we support Unicode 5.1.0", simply because
>> we have not reviewed the all the necessary changes and implications.
>
> Mark's
Bartlomiej Wolowiec wrote:
> For some time I'm interested in regular expressions and Finite State Machine.
> Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
> which very often works too slow. Its pesymistic time complexity is O(2^n),
> although other solutions, with time
Guido van Rossum wrote:
>> What about reimplementing commands.* using subprocess? Or providing a
>> commands.*-compatible interface in the subprocess module?
>
> What does that buy us?
multi-platform support? (commands is Unixoid only, right?)
_
Martin v. Löwis wrote:
> I never considered it an extension. Ask 10 people around you to see
> what a leading dot on Unix in a file name means, and I would be
> suprised if more than one answered "it separates the file name from
> the extension". Most of them likely include "hidden file" in their
Guido van Rossum wrote:
> My suspicion is that building Python for an 64-bit address space is
> still a somewhat academic exercise.
arbitrary 64-bit systems, perhaps. the first Python system I ever built was
deployed
on an LP64 system back in 1995. it's still running, and is still being
maint
Talin wrote:
> Rather than fixing on a standard markup, I would like to see support for
> a __markup__ module variable which specifies the specific markup
> language that is used in that module. Doc processors could inspect that
> variable and then load the appropriate markup translator.
Ideally,
Guido van Rossum wrote:
> Even apart from the website that Samuele found, the content sounded
> genuine. Just not something I feel like dealing with (too many
> surveys).
from what I can tell, it was blasted to everyone with a sourceforge
account, which indicates that they're don't really care w
Martin v. Löwis wrote:
>> 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(
Martin v. Löwis wrote:
>> 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 "res
Kurt B. Kaiser wrote:
> Going mainstream :-))
indeed. from what I can tell on my local market, we've "crossed the chasm"
[1], and
are seeing wider range of "pragmatists" adding Python to the tool chain.
> The Rails buzz seems to be jumping to Python lately.
fwiw, the people I see pick up Pyth
Guido van Rossum wrote:
> That was the month of October.
>
> If people believe these numbers are real, we're doing great!!!
2.5 was of course released in september, so I assume that part of
what you're seeing is simply tinkerers upgrading their existing
installations.
plotting weekly figures f
Talin wrote:
> The original proposal was to make m[n] a synonym for m.group(n).
> "group()" is clearly map-like in its behavior.
so have you checked what exception m.group(n) raises when you try to
access a group that doesn't exist ?
frankly, speaking as the original SRE author, I will now fli
Talin wrote:
> Maybe instead of considering a match object to be a sequence, a match
> object should be considered a map?
sure, except for one small thing. from earlier in this thread:
> Ka-Ping Yee wrote:
>
>> I'd say, don't pretend m is a sequence. Pretend it's a mapping.
>> Then the co
Michael Urman wrote:
> The idea that slicing a match object should produce a match object
> sounds like a foolish consistency to me.
well, the idea that adding m[x] as a convenience alias for m.group(x)
automatically turns m into a list-style sequence that also has to
support full slicing sound
M.-A. Lemburg wrote:
> This was added to make the transition to all Unicode in 3k easier:
thanks for the clarification.
do you recall when this was added? 2.5?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
over at my work copy of the python language reference, Adrian Holovaty
asked about the exact semantics of the __str__ hook:
http://effbot.org/pyref/__str__
"The return value must be a string object." Does this mean it can be a
*Unicode* string object? This distinction is ambiguous to me
Steven Bethard wrote:
> Fredrik Lundh has been working on a `new Python FAQ`_
footnote: working on cleaning up the old FAQ, to be precise. it'll end
up on python.org, as soon as Andrew Kuchling gets around to complete his
FAQ renderer (which may take a while, since he's busy wi
Martin v. Löwis wrote:
> In any case, having Python in the LSB means that ISVs (software
> vendors) who target LSB (rather than targetting specific Linux
> distributions) could develop their applications also in Python
> (whereas now they have to use C or C++).
... without having to include a Pyt
Alastair Houghton wrote:
> (The current groups() method *doesn't* match those expectations,
> incidentally. I know I've been tripped up in the past because it
> didn't include the full match as element 0.)
that's because there is no "group 0" in a regular expression; that's
just a historica
Ben Wing wrote:
> i'm ok either way -- that is, either with the proposal i previously
> published, or with this restricted idea.
ok, I'll whip up a patch for the minimal version of the proposal, if
nobody beats me to it (all that's needed is a as_sequence struct with a
item slot that basically
Ka-Ping Yee wrote:
> I'd say, don't pretend m is a sequence. Pretend it's a mapping.
> Then the conceptual issues go away.
almost; that would mean returning KeyError instead of IndexError for
groups that don't exist, which means that the common pattern
a, b, c = m.groups()
cannot be rewr
Martin v. Löwis wrote:
>> 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?
I haven't seen a comp
Martin v. Löwis wrote:
>> I know what the Zen says about special cases, but in this case the rules
>> were apparently broken with impunity.
>
> Well, the proposal was to interpret m[i] as m.group(i), for all values
> of i. I can't see anything confusing with that.
it can quickly become rather co
Martin v. Löwis wrote:
>> 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 match.
Martin v. Löwis wrote:
> 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 much con
Martin v. Löwis wrote:
> Several issues need to be taken into account:
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
Martin v. Löwis wrote:
>> 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 _tk
Frank Lomax wrote:
> The PSU does not, nor ever has existed. Any statement implying
> otherwise is false and subversive. There is no PSU and even if there
> is, it has no influence whatsoev
it's a bit interesting that every time someone writes something along
those lines, their computer's P
Guido van Rossum wrote:
>> it would be a good thing if it could, optionally, be made to report
>> horizontal whitespace as well.
>
> It's remarkably easy to get this out of the existing API
sure, but it would be even easier if I didn't have to write that code
myself (last time I did that, I nee
Guido van Rossum wrote:
> Are you opposed changing tokenize? If so, why (apart from
> compatibility)? ISTM that it would be a good thing if it reported
> everything except horizontal whitespace.
it would be a good thing if it could, optionally, be made to report
horizontal whitespace as well.
Talin wrote:
> But it isn't just the docs that are at fault here - otherwise, I'd be
> posting this on a different mailing list. It seems like the whole
> architecture is 'diff'-based, a series of patches on top of patches,
> which are in need of some serious refactoring.
so to summarize, you
tomer filiba wrote:
> no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
>
> while limit > 0:
> limit -= len(chunk)
>
> with limit = posinf, the above code should be equivalent to "while True".
that's a remarkably stupid way to count bytes. if you want to argue for
Armin Rigo wrote:
> Yuk! Not renamed to .py files. Distributing .py files that are
> actually bytecode looks like a new funny way to create confusion. No, I
> was half-heartedly musing about introducing Yet Another file extension
> (.pyc for caching and .pyX for importable bytecode, or possibly
Ka-Ping Yee wrote:
> Wow. Did you catch this news?
>
> http://www-tech.mit.edu/V125/N65/coursevi.html
>
> The first four weeks of C1 will be a lot like the first
> four weeks of 6.001, Abelson said. The difference is
> that programming will be done in Python and not Scheme.
"This s
Martin v. Löwis wrote:
> 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 i
(reposted from c.l.py)
the following FAQ item talks about using sleep to make sure that threads
run properly:
http://effbot.org/pyfaq/none-of-my-threads-seem-to-run-why.htm
I suspect it was originally written for the "thread" module, since as
far as I know, the "threading" module takes care of
Guido van Rossum wrote:
> IMO it was an oversight. Or we were all exhausted. I keep copying
> those three classes from the docs, which is silly. :-)
I'll whip up a patch. would the "embedded python module" approach I'm
using for _elementtree be okay, or should this go into a support library ?
Martin v. Löwis wrote:
>> 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
I was more think
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?
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Martin v. Löwis wrote:
> 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: pas
Guido van Rossum wrote:
> I think that ought to go into the guidlines for what's an acceptable
> __dir__ implementation. We don't try to stop people from overriding
> __add__ as subtraction either.
to me, overriding dir() is a lot more like overriding id() than over-
riding "+". I don't think a
Thomas Heller wrote:
>>> No objection on targetting 2.6 if other developers agree. Seems this
>>> is well under way. good work!
>>
>> given that dir() is used extensively by introspection tools, I'm
>> not sure I'm positive to a __dir__ that *overrides* the standard
>> dir() behaviour. *adding*
Guido van Rossum wrote:
> No objection on targetting 2.6 if other developers agree. Seems this
> is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir() behaviour. *adding* to the defaul
Andrew Dalke wrote:
>> as I said, today's urljoin doesn't guarantee that the output is
>> the *shortest* possible way to represent the resulting URI.
>
> I didn't think anyone was making that claim. The module claims
> RFC 1808 compliance. From the docstring:
>
> DESCRIPTION
> See
Martin v. Löwis wrote:
> Andrew Dalke schrieb:
> urlparse.urljoin("http://blah.com/";, "..")
>> 'http://blah.com/'
> urlparse.urljoin("http://blah.com/";, "../")
>> 'http://blah.com/../'
> urlparse.urljoin("http://blah.com/";, "../..")
>> 'http://blah.com/'
>>
>> Does the result make s
Steve Holden wrote:
>> Ah, but how do you know when that's wrong? At least under ftp:// your
>> root is often a mid-level directory until you change up out of it.
>> http:// will tend to treat the targets as roots, but I don't know that
>> there's any requirement for a /.. to be meaningless (even
Martin v. Löwis wrote:
> However, I find the proposed behaviour reasonable: Python already
> automatically imports the .pyc file if .py is not given and vice
> versa. So why not look for .pyo if the .pyc file is not present?
well, from a performance perspective, it would be nice if Python looked
Steve Holden wrote:
> Although the last two smell like bugs, the point of urljoin is to make
> an absolute URL from an absolute ("current page") URL
also known as a base URL:
http://www.w3.org/TR/html4/struct/links.html#h-12.4.1
(os.path.join's behaviour is also well-defined, btw; if any
Chris Barker wrote:
> While /F suggested we get off the PIL bandwagon
I suggest we drop the obsession with pointers to memory areas that are
supposed to have a specific format; modern data access API:s don't work
that way for good reasons, so I don't see why Python should grow a
standard based
[EMAIL PROTECTED] wrote:
> I assert that it needs a better[1] interface because the current
> interface can lead to a variety of bugs through idiomatic, apparently
> correct usage. All the more because many of those bugs are related to
> critical errors such as security and data integrity.
in
Jonathan Lange wrote:
> Then let us discuss that.
Glyph's references to bike sheds went right over your head, right?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
[EMAIL PROTECTED] wrote:
> I am not addressing this message to the py3k list because its general
> message of extreme conservatism on new features is more applicable to
> python-dev. However, py3k designers might also take note: if py3k is
> going to do something in this area and drop support
Terry Reedy wrote:
> I believe that at present PyGame can only work with external images that it
> is programmed to know how to import. My guess is that if image source
> program X (such as PIL) described its data layout in a way that NumPy could
> read and act on, the import/copy step could b
Talin wrote:
> I'm right in the middle of typing up a largish post to go on the
> Python-3000 mailing list about this issue. Maybe we should move it over
> there, since its likely that any path reform will have to be targeted at
> Py3K...?
I'd say that any proposal that cannot be fit into the
Josiah Carlson wrote:
> I think that even on 64 bit platforms, using 'int' or 'long' generally
> means 32 bit. In order to get 64 bit ints, one needs to use 'long long'.
real 64-bit platforms use the LP64 standard, where long and pointers are
both 64 bits:
http://www.unix.org/version2/wha
Talin wrote:
>> You probably want to use the posixpath module directly in that case,
>> though perhaps you've already discovered that.
>
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
http://effbot.org/librarybook/posixpath.
[EMAIL PROTECTED] wrote:
> I'm not sure what a "pebkac" problem is.
http://en.wikipedia.org/wiki/PEBKAC
You'll learn some new nonsense every day ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Larry Hastings wrote:
> Am I correct in understanding that changing the Python minor revision
> number (2.5 -> 2.6) requires external modules to recompile?
not, in general, on Unix. it's recommended, but things usually work
quite well anyway.
___
Josiah Carlson wrote:
> It would be a radical change for Python 2.6, and really the 2.x series,
> likely requiring nontrivial changes to extension modules that deal with
> strings, and the assumptions about strings that have held for over a
> decade.
the assumptions hidden in everyone's use of th
Talin wrote:
> Interesting - is it possible that the same technique could be used to
> hide differences in character width? Specifically, if I concatenate an
> ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
> be done lazily?
of course.
and if all you do with the resul
Larry Hastings wrote:
> I knocked out a prototype of this last week, emailed Mr. Lundh about it,
> then forgot about it.
It's on my TODO list, so I haven't forgotten about it, but I've been (as
usual) busy with other stuff. I'll get there, sooner or later.
Posting this to the patch tracker an
Anthony Baxter wrote:
> > why not just do a "2.3.5+security" source release, and leave the rest to
> > the downstream maintainers?
>
> I think we'd need to renumber it to 2.3.6 at least, otherwise there's the
> problem of distinguishing between the two. I'd _hope_ that all the
> downstreams will h
Steve Holden wrote:
> Or you can start to promote Django again ...
my original plan would still work, I think:
http://effbot.org/zone/pydotorg-cache.htm#todo
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Martin v. Löwis wrote:
> In 2.3.6, there wouldn't just be that change, but also a few other
> changes that have been collected, some relevant for Windows as well
why not just do a "2.3.5+security" source release, and leave the rest to the
downstream maintainers?
Alexey Borzenkov wrote:
>> any reason you cannot just use the "subprocess" module instead, like
>> everyone else?
>
> Oh! Wow! I just simply didn't know of its existance (I'm pretty much
> new to python), and both distutils and SCons (I was looking inside
> them because they are major build system
Anthony:
>> Sure - I get that. There's a couple of reasons for me doing it. First is gpg
>> signing the release files, which has to happen on my local machine. There's
>> also the variation in who actually builds the releases; at least one of the
>> Mac builds was done by Bob I. But there could be
Nick Coghlan wrote:
> > would collapse to
> >
> > static PyTypeObject NoddyType;
>
> Wouldn't that have to be a pointer to allow the Python runtime complete
> control of the structure size without recompiling the extension?:
>
> static PyTypeObject *NoddyType;
yeah, that's a silly typo.
Anthony Baxter wrote:
>> For reference, here's my effbot.org release procedure:
>>
>> 1) upload the distribution files one by one, as soon as they're
>> available. all links and stuff will appear automatically
>>
>> 2) update the associated description text through the web, when
>> necessary, as
Alexey Borzenkov wrote:
> P.S. Although it's a bit stretching, one might also say that
> implementing spawn*p* on windows is not actually a new feature, and
> rather is a bugfix for misfeature. Why every other platform can
> benefit from spawn*p* and only Windows can't? This just makes
> os.spawn*
1 - 100 of 732 matches
Mail list logo
