> Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing
> in Windows I would vote for more time for stabilizating things - not
> adding new features. Long awaited subprocess as replacement for
> os.popen() AFAIK is still incapable to asynchronously communicate with
> spawned proces
> I've reported bug http://bugs.python.org/issue5924 some time ago and I
> think it's a release blocker -- it seems easy to fix, but I don't have
> time to actually submit a patch, so, I'd like to draw attention to it,
> especially as a release candidate is already out.
In absence of a patch, it c
> I have a few questions about validating SSL certificates. From what I
> gather, this validation occurs in the OpenSSL code called from _ssl.c.
> Is this correct?
This question is really off-topic for python-dev. As a python-dev
poster, you should do research upfront, and only post on what you
co
>> This question is really off-topic for python-dev. As a python-dev
>> poster, you should do research upfront, and only post on what you
>> consider facts.
>
> Martin, I told him to ask his question about _ssl internals on
> python-dev as he is new, and looking to work on some of the
> internals/
> If this isn't the place to ask these kinds of questions, I apologise.
> I can take the discussion elsewhere if I need to.
It really depends on what "these questions" are. If your question is
"I have this patch, is it correct?", then the question is entirely
appropriate. If it is "I just have bar
> 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'll be able to review the changes, maybe he can
accept releasing control of xmlrpc
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 releasing control of xmlrpclib.
>
> Pointer to the patch?
http://bugs.python.org/issue6267
While I have your attention, p
> For better or for worse, I have created a patch against the py3k trunk
> which introduces a binary operator '@' as an alternative syntax for
> the new string formatting system introduced by PEP 3101 ("Advanced
> String Formatting"). [1]
I'd like to join everybody else who said that this would be
> Of course I could program the above, but I was
> hoping to avoid duplicated effort if someone has
> already programmed options like this..
In this specific form, the question is off-topic for python-dev,
and better asked on python-list (in particular since it has a wider
audience).
On-topic wou
> Comments?
I don't think there is any need to support that in the Python core.
Instead, if you find such a functionality useful, feel free to implement
it yourself, and share it with others.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pytho
> Can you tell me which modules provide to
> decode and execute a .pyc file ?
The bytecode loader in in marshal.c; the byte code interpreter is in
ceval.c. Also consider frameobject.c and codeobject.c.
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@
> Now to my real question. I have noticed that PyThread_acquire_lock
> swallows all signals with pthread using sems. Looking at the source code
> it appears that this is intended, but I cannot see the reason for that.
> It seems the pthread sem implementation is the only one doing so. Can
> any of
Python 2.4 will become 5 years old this November. I plan to make the
final security release this month or next month. If you want to see
additional patches in Python 2.4, please let us now, or commit them
yourself if you can.
Remember that only security fixes can be considered for inclusion,
and p
> If no one objects, I'd like to push PEP 376 in the "accepted" status
> and go ahead with its implementation,
> with continuous feedback at Distutils-SIG as we did to build it.
I think this isn't quite the process. In the past, every PEP required
BDFL pronouncement, which you should now seek.
Re
> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
This is my understanding as well - so I don't think Python actually
"swallows" the signal.
> A great example is reading from a socket. Whether or not it can be
> interrupted depends on the platform, so catching Ctrl+C often
> - Post that to python-list, with a note pointing to the PEP for people
> who care about distutils details
If that hasn't been done before (I have not followed), it should be done
right away. PEP 1 makes it a mandatory requirement for acceptance.
Regards,
Martin
_
Tarek Ziadé wrote:
> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote:
>> - The terminology and focus feels setuptools-inspired (my apologies if
>> that's not the case). Expect pushback from setuptools haters...
>
> setuptools implemented *needed* features, like a way for developers to browse
> i
> I dunno what the right solution is.
I feel that it is straight forward. Either provide a
/usr/bin/python-uninstall utility, or arrange to make
python -mdistutils.uninstall work, so one would do
python -mdistutils.uninstall some_package
Regards,
Martin
__
> PS: if this gets fixed somehow, can the fix be backported to the
> Python 2.5.x releases?
Definitely not - it's not security critical.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
> So we must work without effective EOL support?
If that's the case (i.e. no effective EOL support, the way svn
supported it), then I think the PEP should make that clear (e.g.
in a discussion section).
For the server-side hooks: it would be good to know exactly
what they check, wrt. line endings
> It will handle it, for sure, but I think it would all go easier if we
> could work with stricter subset branches (and leave the effective
> cherrypicking for the occasional problem).
So I think the PEP should propose a workflow (or: merge flow) if you
think we would be better off with a differen
> Should we consider adding a sys.revision attribute and begin the
> deprecation of sys.subversion?
I wouldn't mind killing sys.subversion "right away" (i.e. in trunk
and 3k - obviously it has to stay in 2.6 and 3.1, and all the older
branches).
I'm -1 on calling it "sys.revision", as this makes
>> This is exactly why I was asking for your advice - I can't work out how to
>> work effectively with win32text as it stands myself, so remain stuck
>> accidently checking in files with inappropriate line endings and stuck
>> working out how to move pywin32's CVS repo with abandoning the very
>> p
I have now turned the 3.0 buildbots off, and created new
builders for 3.1.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
> We could add another value in the tuple that specifies the VCS:
> ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that
> VCSs are not universally the same, but the concept of a revision is
> universal.
Actually, I think that's not the case. For bzr, the usual way of
identifying
> So are you saying we should drop the idea of a revision value
> altogether, or just embrace the differences and add a sys.mercurial
> attribute?
That's what I would propose. It should be a best-effort(*) approach at
providing all information that is needed to really find the source
used for the
> - First of all, I've got the basic conversion down, I've done it a few
> times now, with progressively better results. You can view some
> results at http://hg.python.org/, which has a preliminary cpython
> repository. *** The changeset hashes for that repo will change, so you
> won't be able to
Barry Warsaw wrote:
> On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote:
>
>> I'm -1 on calling it "sys.revision", as this makes it difficult to
>> tell what the actual versioning system was, and hence how the
>> data should be interpreted. It will already b
> Doesn't Mercurial support an Subversion bridge? Would it be possible to
> provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6,
> and 3.1? If so, then the release managers would simply have to cut
> their releases from the svn copy instead of the hg master. /All/ other
> wor
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>> I would drop the roundup integration from the things that need to
>> be done pre-migration - there currently is no svn integration, so
>> not having it for hg is not a step backwards.
>
> That's not quite true - the
> I see that George Brandl and Martin van Loewis seem to be accomodating
> your viewpoint, but I don't get the impression that either you (as the
> hg migration proponent) nor they (as core committers) realize how far
> apart your assumptions are.
Actually, I (probably) don't agree to a merge flo
>> In proposing such a workflow, consider these requirements:
>
> It seems that there is a consensus to separate the 2.x and 3.x repos,
> and that also makes sense to me.
(I think) I wasn't primarily talking about the representation of
branches in hg - to that, I fully trust recommendations from
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
So far, I have only one item: build identification. If you want to work
on this, please either provide a patch (for trunk and/or py3k), or
(if you are a co
> I do want to help, but I believe I'll only have time a week from now.
> If we need/want Roundup tweaks to go with Mercurial, I can work on
> that (keep in mind we have a cool GSoC student working on
> Mercurial-Roundup integration, and I'm willing to work on our needs
> with him).
I think that's
> I suggest that we also run a version of that redirection filter to remap
> the old svn.python.org links in addition to making them accessible
> through hg.python.org as Dirkjan proposed.
Not sure what links you are talking about, but we also need to keep the
current svn.python.org up as-is, for
M.-A. Lemburg wrote:
> Dirkjan Ochtman wrote:
>> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
>>> Is there a standard notation for hg revisions that roundup could
>>> detect and turn into links (much like it does for svn) ?
>> [a-f0-9]{12} should mostly do.
>
> Hmm, no prefix or suffix ?
>
>> Hmm, no prefix or suffix ?
>
> No, not really. hg often shows revision integers as well, but as they
> aren't globally consistent, they're of little value in communicating
> changeset pointers.
I think MAL wasn't asking for a "1354:" prefix, but for a, say,
"r" or "R" prefix, or perhaps "V" or
>> I've seen a few discussions about this, but no final statement
>> of what strategy to follow and whether hg makes this easier (AFAIR,
>> that was the main argument for switching to hg).
>
> I think the main reason for switching was that it would make it easier
> for non-core-committers to maint
> Since many C applications take argv as a (char **) it seems reasonable
> for python to keep a function for the C api that accepts a (char **)
> argument for argv.
I'm not quite sure what you are suggesting: either that there is a
function in the C API that accepts a (char**), or that PySys_SetA
> The reason I was a big vague is that I'm not really bothered HOW its
> done, I'd just like there to be some way to use PySys_SetArgv with a
> (char **)
Ok, that's easy:
void PySys_SetArgvChar(int argc, char** argv)
{
PySys_SetArgv(0, NULL);
}
So you don't bother *how* it's done as long as yo
>> Hehe very nice, thanks for the explanation :)
>>
>> (thanks to the others too)
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high
>> There seem to be two places to plausibly introduce a change: py3k and
>> trunk. Should I submit changes for trunk, py3k, or both? I tried
>> asking in the initial feature request, but nobody replied, and I finally
>> decided that I'd go for patching trunk in the interim.
>
> Patches are usual
Terry Reedy wrote:
> Before posting http://bugs.python.org/issue6453
> I searched the tracker for 'bool TypeError' to avoid making a duplicate
> report. A few irrelevant hits were return but not the important one
> http://bugs.python.org/issue6428
> which was the one I needed to find.
When I searc
According to
http://hg.python.org/cpython/tags?revcount=50
the tag r301 belongs to revision be32850b093f. However, this
is really r69557, which was not tagged. be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
Regards,
M
> I am trying to build Python 3.1 on Windows XP Pro (32 bit) using
> Microsoft Visual C++ Express Edition in order to test some modifications
> I made to the _subprocess.c file as part of my Google Summer of Code
> proposal.
As a posting guideline, please be careful to not post too many messages
Hagen Fürstenau wrote:
>> be32850b093f is listed
>> as having a child revision, 52b0a279fec6, and ISTM that *this*
>> should be the revision that got tagged.
>
> I think the tag is correct. Note that the concept of tagging is
> different in Mercurial, where a tag can only refer to a revision
> pre
> My question is the following :
>
> - What are the implications for Py users ?
After reading your message, I had a difficult time getting your point,
or even finding out what your question is.
So I stick with what you said is your question: What are the
implications for Py users ?
To this, the
> Is that considered a mingw bug?
Perhaps. I can't test right now: *if* VS has a long double type
that is smaller, it is apparently an ABI violation for mingw to
not follow VS. It appears that other people also consider it a
bug:
http://www.velocityreviews.com/forums/showpost.php?p=1514923&postco
Roumen Petrov wrote:
> Martin v. Löwis wrote:
> [SNIP]
>> No. tim_one changed it to be long double in r25454 to support some
>> system that Dave Abrahams uses, so it needs to stay that way :-)
>>
>> However, we can certainly acknowledge that this is a bug in MingW,
>> What do you propose for doing proper alignment, then?
>
> May be "void* dummy[4]" is better for force alignment ?
That would have the same alignment as a single pointer.
> What about alignment on platforms with pointers > 32 bit ?
The C compiler will choose the alignment of the union to be t
> When stdout is console and not redirected to [pipe|file],
> sys.stdout.write(u"foo")
> can avoid encoding and use WriteConsoleW(L"foo")
I think this would be fairly difficult to implement given
the way the output libraries work. If you think it can be
done, please provide a patch to bugs.python.
> Can I ask that you also provide a link for windows users
> to my project:
>
> http://sourceforge.net/projects/pythonpkgmgr/
I fail to see how this project is relevant in the context
of explaining distutils. So you would have to come up with
a proposal of specific wording that makes the releva
> It's my intention to get a Package Manager included in standard
> python - yes.
In addition to the other constraints you'll have to meet for this
to happen, you also have to wait a rather long time (several years)
before inclusion becomes possible. This time is necessary for the
community to acc
> This is fixed in the trunk (Revision 72880), but there has been number
> of valid requests to backport it Python 2.6. While I agree and ready
> to backport to Python 2.6, I would like to ask here if there are any
> objections in this front.
In msg76855 Greg ruled that it is a new feature, and th
> To Martin: So I disagree. The gc header is not responsible for
> alignment in the first place, but to propagate it, correctly.
I think we are in agreement in this respect. That's the whole point
of the long double: to make the gc head's alignment the maximum
alignment on that platform
> And thi
>> This may not be recognized so far, because there is no builtin
>> GC-enabled type that embeds a double.
>> But if you create such a type, then the double will be correctly
>> aligned in your object's structure, but then, when the object
>> gets allocated, it is misaligned, because the header siz
> Antoine Pitrou pitrou.net> writes:
>> In any case, you seem to be right on this particular point: the PyGC_Head
>> union
>> should probably contain a "double" alternative in addition to the "long
>> double"
>> (and perhaps even a "long long" one).
>
> Sorry, I realize that this doesn't really
> For that reason, I don't like the addition of the opaque header
> too much. If there were an option to make the header explicit,
> we would not have to round up the object size to a multiple
> of (8, 16), but could arrange embedded doubles as they fit the best.
We could add the gc head *after* t
>> Why is that difficult? It's sizeof(PyGC_Head).
>
> Is it enough to correctly propagate the alignment for, say, a long double in
> the following PyObject? I'm sorry, I'm not enough of a C lawyer.
Yes, sizeof must always be a multiple of the alignment. Otherwise, array
elements would be misalign
> We could add a PY_LONG_LONG to the mix just in case.
> By the way, will this kind of thing be frozen by the PEP ABI?
Yes: alignof(PyGC_HEAD) would be specified as being the maximum
alignment on a platform; sizeof(PyGC_HEAD) would be frozen. The
actual content would not be frozen, i.e. it could b
>Maximum alignment currently on x86 is 16 bytes for SSE vector
> types. Next year AVX will add 32 byte types and while they are
> supposed to work OK with 16 byte alignment, performance will be better
> with 32 byte alignment.
That doesn't really matter. What matters is the platform's ABI, i.e
> You can't seriously expect users to wait for years for an integrated
> package management tool. Especially on Windows - that's cruel :-)
Hmm. I'm -0 on providing a tool whose only purpose is to download
files from a web server. I always use a web browser for that...
> A Package Manager isn't a
>> If they read examples, they will see import
>> statements, and then they have to find out how to make those work.
>> Does your tool help with that?
>
> Yes. It will open the website or homepage to the project/package
> in question.
How does it know the project in question?
> Using pythonpkgmg
>> I'm a user, and personally I don't want Yet Another Integrated Package
>> Management Tool. What I really want is the ability to install Python
>> packages using the PM tool I already use, namely yum.
>
> ok - but no alternative to that is available on windows.
For removal of packages, an al
>>> pythonpkgmgr is not so different to that. And the idea behind it is
>>> to bring consistancy in package management across the different
>>> platforms.
>> At the cost of being inconsistent within a platform.
>
> It has the most generic of user interfaces.
>
[...]
>
> So I respectfully say th
>> So there are now two incompatible ways to install a package:
>> either with the native manager, or with pythonpkgmgr. If you install
>> them one way, and try to remove them the other way, you lose.
>
> pythonpkgmgr is only a thin wrapper for easy_install/pip.
>
> If there is a problem, then it
> empty: keep-clone?
I use that as a branch to tell build slaves to clean out their
current checkouts. So keep-clone sounds right, assuming it is possible
to target buildslaves at either clones or branches (which, IIUC, would
be necessary anyway, since we are using a mix of branches and clones).
>I haven't commented on this issue before because I can't really be
> helpful. I just don't understand why hg is being considered before
> it's Windows support is roughly equivalent to svn and cvs.
Is it really that you don't *understand*? It's fairly easy: there was
a PEP which offered a numb
> If things were different, they'd be different. However, we live with the
> legacy of that stupid set of decisions and have no real option to
> resolve it permanently short of deprecating entire vistas of tools (or
> even entire operating systems).
I think you missed the solution to the problem t
This is a repost from a month ago. It didn't get much feedback last
time. I have now two items.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
The first item is build identification. If y
>> Now, the specific outcome of the process means that more work needs to
>> be done. So we have a *second* PEP, and we have a lack of volunteers
>> that help implementing it. The second PEP hasn't been approved yet
>> (as it isn't complete, yet), so migration to hg is stalled.
>> The primary volun
>> As already mentioned in this thread, a capability similar to what svn
>> or cvs offers would be sufficient.
>
> That capability presented by centralised VCSen is entirely dependent on
> the fact that they *are* centralised. Using a distributed VCS means the
> same capability doesn't apply.
Why
>The PEP process is straightforward. However, a PEP may produce an
> outcome that proves after more experience to be wrong. ISTM a
> prerequisite to choosing a DVCS is that it should support the full
> range of development platforms and thus the PEP was accepted
> prematurely.
To be as blunt a
> - we're a distributed system, there's fairly little we can assume about
> clients
Not as Mercurial, no. As Python, we can certainly expect that all of our
contributors have read the developer FAQ, and set up their systems
accordingly. If all else fails, we can revoke commit access (or is
it "pu
>> Not as Mercurial, no. As Python, we can certainly expect that all of our
>> contributors have read the developer FAQ, and set up their systems
>> accordingly. If all else fails, we can revoke commit access (or is
>> it "push access"?) if some committer doesn't get the configuration
>> right. We
> I'm not sure how win32text will provide anything other than
> performance degradation for non-Windows developers, but if there's
> functionality to be had, I'm happy to mandate its use on every
> platform.
This is all fairly hypothetical - if hg grew a .hgeols file, it would
be good if it suppor
>> Given that my preference is to use Unix-style EOL for "text" files on
>> Windows, as every text editor I use (barring notepad!) understands LF
>> format, it seems to me that this proposal also means that the hook
>> would be optional for me. That suits me fine - I'd prefer to avoid
>> having hoo
>These files are in 8859-1 encoding (names in comments, at least):
> http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
> http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
> http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
> http://svn.python.org/view/pytho
>>These files are in 8859-1 encoding (names in comments, at least):
>> http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
>> http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
>> http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
>> http://svn.python.org/view/
> >Dirkjan, how does Mercurial handles charsets? If I have three files in
> > my repository - one in utf-8, another in koi8-r, and the third in cp1251
> > encoding - I certainly don't want to convert them back and force, but I
> > want hg web interface to provide charset in the Content-Type
> I'm not aware of any other unresolved items; they may exist, but the fact
> that they're not discussed on this list in detail means that they are
> largely unimportant.
There is a long list of things that still need to be done; each one
potentially creating new problems. In particular:
- the .hg
> > Just in case my previous message gets overlooked: PEP 8 mandates Latin-1
> > for Python 2.x source code (except for files that test PEP 263).
>
> You're right, sorry for the misinformation.
>
> An exception should be made for gettext message files, too?
In principle, perhaps. However, Pyth
> This is simply false AFAICS. There was little participation on this
> particular issue during PEP 374 that I can recall. Now that it is
> clearly an issue after all, it's still early in the PEP 385 process.
> Martin has already picked up the ball on EOL support, and has carried
> informal desig
> What's the last revision supposed to be? I keep a somewhat regularly
> updated full sync of the Python repo.
We don't know exactly; python-checkins has recorded r74352. If anybody
has a more recent checkout (svn info .), please speak up.
Regards,
Martin
_
> The following sites are up again on a new machine
I'd like to thank the people who have helped getting the temporary
machine up: Thomas Wouters spent much of his day at XS4ALL, where
he was helped by Gerben Schepers (who also provided the hardware).
Sean Reifschneider provided the backups (from
> The reason I came across the old patch was because I was searching
> for something that did exactly what compose does. That is to say, I
> had a use case that was compelling enough that I thought there should
> be something in functools to do what I wanted. I've encountered this
> pattern often
> Then I wonder how partial() ended up in the stdlib.
PEP 309 was written, discussed, approved, and implemented - that's how
partial ended up in the stdlib. The feature itself might be debatable,
that's what we have the PEP process for.
> Either we decide it is useful to have a set of basic "fun
Martin v. Löwis wrote:
>> The reason I came across the old patch was because I was searching
>> for something that did exactly what compose does. That is to say, I
>> had a use case that was compelling enough that I thought there should
>> be something in functools to
> So where does the Py_DECREF() for the above Py_INCREF() live? I
> expected to find this code snippet somewhere, but couldn't:
>
> if (type->tp_flags & Py_TPFLAGS_HEAPTYPE)
> Py_DECREF(type);
For a regular heaptype, it's in subtype_dealloc:
/* Can't reference self beyond
> Thanks for the pointer. I noticed that subtype_dealloc is only called for
> types
> that are allocated using type_new(). Does this mean that it is not
> safe to create
> types in C using just PyType_Ready() and set Py_TPFLAGS_HEAPTYPE on
> them? The documentation is not clear on this point.
>> PEP 309 was written, discussed, approved, and implemented - that's how
>> partial ended up in the stdlib.
>
> Ok, I'm surprised that a single addition to a module needed a PEP in
> order to be approved.
A PEP is generally needed if there is no easy consent achievable. It's
not (primarily) the
>> As Benjamin says, this is getting off-topic - python-dev is not a place
>> to ask for help in your project.
>
> Please let me know where is a more suitable place to discuss the
> implementation of the cPython as it pertains to C extensions. I wrote
> to python-dev only because the other lists a
> and I don't see any reason why a compose() function shouldn't do the
> same.
I was tricked into reading it different when used with getters, i.e.
l.sort(key=compose(attrgetter('name'),attrgetter('age')))
is too easy (IMO) to read as applying foo.name.age on all elements of
the list.
> (Asi
> I have never found these arguments compelling. They are obviously not
> true (e.g., itertools.compress()[1] added in 2.7/3.1), and so what I
> really hear is: "I don't like it and I outrank you."
That certainly contributes to it - if you are not a committer, you have
to find a committer that fin
Guido van Rossum wrote:
> Hm... I thought the address was p...@python.org?
>
> On Mon, Aug 17, 2009 at 8:19 AM, Eric Pruitt wrote:
>> Several days ago, around the time the python.org servers went down, I
>> submitted a PEP to edi...@python.org. When things to have been worked,
>> I submitted the P
This is a repost from two weeks ago. It didn't get much feedback last
time. I still keep trying, reposting to python-list also this time.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
Th
>>> Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?)
>> 2.5 needs VS 2003.
>
> The 64 bits version of 2.5 is built with VS 2005, though.
Not really - it is built with the compiler in the platform SDK.
Regards,
Martin
___
Python-Dev mailing
> No, I just said its conventionally used as that but its not definition
> of a broadcast (in fact you can have any valid host address defined
> as broadcast as long as all members of the network agree on that)
You could, but then you are violating existing protocol specifications.
RFC 1122 manda
> Now on to the complaints: Though I recently added support for this in
> Jython, I don't like that nodes can be defined without required
> attributes, for example:
>
> node = ast.Assign()
I think we disagree in two points in our evaluation of this behavior:
a) ast.Assign is *not* a node of the
> x = compile("def foo():pass", "foo", "exec", _ast.PyCF_ONLY_AST)
>
> Does x contain real AST nodes or does it contain mirror structures
> (feel free to just tell me: don't be lazy, go read the code).
It only contains a mirror structure. See
pythonrun.c:Py_CompileStringFlags, and the (generated)
501 - 600 of 5277 matches
Mail list logo
