nd ability to provide
that guidance. So this is really a call for opinions on "how should we
do platform-specific conditions".
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
ame on any machine,
so I'm quite happy with it being static.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
M
ain. Right now, status quo and the lack of a volunteer to update the
web site means that sticking with the 32-bit link is easier to explain
than having to figure out why a particular machine was offered a
particular download when it is not correct.
Cheers,
Steve
_
On Tue, Jun 18, 2019 at 9:37 PM Steve Dower wrote:
> On 18Jun2019 1025, Stephen J. Turnbull wrote:
> > Oleg Broytman writes:
> > > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com
> wrote:
> >
> > > > Why don't we che
On 19Jun2019 0124, Steve Holden wrote:
I just posted a webmaster reply about just such an inquiry. As one of
the people who get to do the explaining, it would be nice if we (not the
devs) could figure out some way of getting people to the download they want.
Probably the easiest thing to do
identifier
is not practical.
Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
What benefit would this provide? And why is a non-ASCII identifier not
practical?
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
ou're
talking about"), so I'm going to drop the MinGW lib from 3.8 and update
the docs with instruction.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
htt
more details at Python-list Info Page
<https://mail.python.org/mailman/listinfo/python-list>.
Kind regards,
Steve Holden
On Thu, Jun 20, 2019 at 3:40 AM Ed Peschko wrote:
> all,
>
> I'm writing a function meant to print out the context of a given
> function call when e
themselves.
Developers from numpy, scipy and Anaconda were involved in the discussion.
The section of the porting notes dealing with this issue is
https://docs.python.org/3.8/whatsnew/3.8.html#bpo-36085-whatsnew
Cheers,
Steve
___
Python-Dev mailing list
ovide infrastructure, those who want to make open-ended
donations can use the already existing channels, and those who want
donations directed for development work can now choose that.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To
Excellent thought.
On Fri, Jun 28, 2019 at 6:49 PM Ned Deily wrote:
>
> On Jun 28, 2019, at 12:56, Mariatta wrote:
> > Some of the items brought up during the language summit:
> > [...]
> > - we should be updating devguide ahead of the actual migration, so core
> developers and release managers
itext(p)
>>> p = (p0 + ".html") if os.path.normcase(p1) ==
os.path.normcase(".htm") else p
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mai
ersation
in places where we don't want to have to pay attention to will force
people towards the places where we are paying attention.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le.
'only_start'=True and 'only_end'=True?
>
> Taking swapping a file extension as an example of a particular
> transformation of interest, it would be achieved with something like
> s.replace(".htm", ".html", only_end=True).
>
> -Brian
Ju
uties soon. The duties aren't
heavy, but the traffic is fairly regular and most of it benefits from being
answered sooner rather than later. So if anyone wants to pitch in, you'll
be welcomed.
Kind regards,
Steve Holden
On Mon, Jul 8, 2019 at 10:28 PM Barry Warsaw wrote:
> On Jul 8
ing the need to
seek assistance elsewhere. We see remarkably little spam, so moderating the
list isn't an issue and I've been doing that unaided for over a year
without noticing.
Kind regards,
Steve Holden
On Mon, Jul 8, 2019 at 11:56 PM Ethan Furman wrote:
> On 07/08/2019 03:12
We've tried this before, but apparently people were cross-compiling. I'd
suggest not removing them any faster than whatever deprecation applies to the
module on all platforms (which should still be as quickly as possible :-) ).
Cheers,
Steve
On Mon, Jul 15, 2019 at 5:2
PEP 8 would concur, whatever the current preferred style was. Under "Naming
Conventions":
"""New modules and packages (including third party frameworks) should be
written to these standards, but where an existing library has a different
style, internal consistency is preferred."""
The requirement
g with
If the tests are skipped, you probably did not install the C++ or
"Python Native Development" options for Visual Studio. You can run
"Visual Studio Installer" from Start to change your installed options.
Cheers,
Steve
___
Python-Dev
E_SDK=1 to
disable the automatic detection. In the wrong shell you'll get a broken
build, but it might have unblocked you in this case.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
d once it's public
API, we shouldn't be making it too easy to rename the function anyway ;)
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mail
about making sure
people (including us!) know what the canonical reference for
public/internal is.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailm
On Thu, Jul 25, 2019 at 4:01 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I considered an alternative: return True if the underlying dicts were
> identical or equal, and raise an Exception otherwise.
> But I soon decided that this was a terrible idea: it could hide a bug by
> mak
re, as many PRs can't be merged during the sprint itself, and we're
not so good at following up later.)
(As an aside, the best first issue is usually the one the new
contributor cares about most, regardless of difficulty. Finding
something "suitable" for someone with no prefere
only ever see the irrelevant warnings being raised from
docstrings, so if others confirm this perhaps there's a way we could
suppress the warnings where the string is the entire expression?
Cheers,
Steve
___
Python-Dev mailing list -- python-d
erhiy said, once the .pyc exists, you won't
see this warning again.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.pyth
a few
more years without creating more harm.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archi
only
incompatibility there would surely be general delight.
Kind regards,
Steve Holden
On Wed, Aug 7, 2019 at 8:19 PM eryk sun wrote:
> On 8/7/19, Steve Dower wrote:
> >
> > * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to
> > append (or chain) an extra
ating the access
time so that both functions behave the same, but that might be too
complicated.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mai
On 19Oct2020 1242, Steve Dower wrote:
On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
TLDR: In os.scandir directory entries, atime is always a copy of mtime
rather than the actual access time.
Correction - os.stat() updates the access time to _now_, while
os.scandir() returns the last
erformance. But it's almost certainly an option
somewhere, which means you can't rely on it being either true nor false.
You just have to be explicit for certain pieces of information.
If I'm understanding Steve correctly this is due to Windows/NTFS storing
the access time poten
On 19Oct2020 1846, Eryk Sun wrote:
On 10/19/20, Steve Dower wrote:
On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
TLDR: In os.scandir directory entries, atime is always a copy of mtime
rather than the actual access time.
Correction - os.stat() updates the access time to _now_, while
On 20Oct2020 0520, Rob Cliffe wrote:
On 19/10/2020 12:42, Steve Dower wrote:
On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
TLDR: In os.scandir directory entries, atime is always a copy of
mtime rather than the actual access time.
Correction - os.stat() updates the access time to _now_
ut it (e.g. type checkers might warn about
multiple conflicting assignments) seems like an overall happier path,
that neither makes existing code forwards-incompatible nor future code
backwards-incompatible.
I don't think we have to codify every emergent coding pat
or pattern matching to get in before proposing
an expansion, so then you won't be caught out suggesting the wrong thing :)
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
On Wed, Oct 21, 2020 at 8:37 AM Paul Moore wrote:
> On Wed, 21 Oct 2020 at 08:14, Christian Heimes
> wrote:
> >
> > On 21/10/2020 00.14, Steven D'Aprano wrote:
> > > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> > >
> > >> What I don't see is where the money's coming from. It's f
essors do other kinds of
clever things with jumps anyway, that can variously improve/degrade
performance from what the compilers generate.
Benchmarks on consistent hardware are what matter, not speculation about
generated code.
Cheers,
Steve
__
g the language
and never implementing a class (or often, even writing a function).
Having a canonical tutorial to get these users through this stage first
before going deeper would be great.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@pytho
eople will ever need
position-only parameters, for example, and I'd say all special
parameters matter more in the tutorial because of how you _call_ them,
rather than how you define them).
Cheers,
Steve
On 06Nov2020 1714, Guido van Rossum wrote:
I agree with you that the tutorial should
As I remember the webmaster@ discussions, Mats did go so far as to start a
re-write of the classes section, but it never got as far as a PR.
Kind regards,
Steve
On Fri, Nov 6, 2020 at 5:51 PM Guido van Rossum wrote:
> Ouch, that's bad. It seems the class tutorial could use an overhaul
On Thu, Nov 12, 2020 at 8:49 PM Guido van Rossum wrote:
> The correct place for the docs for __cause__ and __context__ is in the
> section in the library reference about exceptions. There's quite a bit
> about them there already. That's where the tutorial should link as well.
>
> And now I ask yo
On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset wrote:
> [sorry for the duplicate, meant to reply-all]
>
> Thank you for this approach, I find it really helpful to put the
> conversation in these terms (semantics and guiding principles).
>
> It does help to rationalise discussion ;-)
> [...]
> 4.
On Wed, Nov 18, 2020 at 7:45 PM Brett Cannon wrote:
>
>
> On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing
> wrote:
>
>> On 18/11/20 4:36 pm, Larry Hastings wrote:
>> >
>> > But,
>> > the thinking went, you'd never want to examine the last value from a
>> > list generator, so it was more convenient i
On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon wrote:
>
>
> On Thu, Nov 19, 2020 at 5:16 AM Steve Holden wrote:
>
>> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset
>> wrote:
>>
>>> [sorry for the duplicate, meant to reply-all]
>>>
>>> Tha
Fair enough.
On Fri, Nov 20, 2020 at 11:45 AM Thomas Wouters wrote:
>
>
> On Fri, Nov 20, 2020 at 8:38 AM Steve Holden wrote:
>
>> On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon wrote:
>>
>> All I will say is just because we aren't *required* to implement it
A general wish not to disadvantage those with older hardware any more than
they already are?
Just a shot in the dark.
On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith wrote:
>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
And yes, "the official
docs aren't good enough for me to follow" is a problem ;) )
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/ma
se :)
I'm not looking to start any mentoring right now, but if someone else is
and you're interested, it should be easy to get you connected. I am more
than happy to endorse you as a good candidate for becoming our SQLite
expert.
Cheers,
Steve
__
rnals will have to get special
treatment.
I don't want to make it all sound too easy, because it probably won't
be. But it should be possible to add a viable proxy layer as a set of
abstract C APIs to use instead of the concrete ones.
Cheers,
Steve
___
On 1/21/2021 6:30 PM, Brett Cannon wrote:
On behalf of the SC, I'm happy to announce that we have chosen to accept
PEP 632. Congrats, Steve, and thanks for the work on the PEP!
I'll let Steve outline what the next steps are for implementing the PEP.
Thanks. Work from this point
If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?
On Mon, Jan 25, 2021 at 5:18 PM Victor Stinner wrote:
> Hi Bernat,
>
> "stdlib_module_names" was my first idea but it looks too long, so I
> chose "module_names"
On 1/26/2021 8:32 PM, Steve Holden wrote:
If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?
And since the modules can vary between platforms and builds, why
wouldn't this be sysconfig.stdlib_names rather
created. If you're still concerned, go pay a lawyer to give you
more opinions, because you honestly aren't going to find a more informed
opinion for free on the internet ;)
Cheers,
Steve
1: See page 8 of
https://visualstudio.microsoft.com/wp-c
hey complain on the
issue tracker. Only thing I'm certain of is that we shouldn't assume
that we know everyone who ever builds CPython.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python
efore UTF-8 was invented and never took the
backwards-incompatible change because they were so popular), but if we
want to pragmatically weigh the needs of our users above our desire for
purity, then we should try and support both equally wherever possible.
Cheers,
My suggestion that it be introduced via __future__ due to its contentious
nature met immediate resistance. No point going down that road.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> With such a large new area of func
Good luck in your quest.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 9:00 PM Ivan Pozdeev wrote:
> Who said "__future__"? I said "3rd-party library". Independent from the
> CPython project.
> Maybe even a few of them -- to try out conflicting visions that emerg
things that affected all foundations.
If you plan to bring this kind of money in and rely on it, you have to
ensure it comes from sources that can't just be switched off when budgets
tighten. It could be done, but "easy" sounds like exaggeration t
ve work before doing a release.
Actively blocking anything at all seems unnecessary at the source/build
level. That's for pre-built binaries and other conveniences.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubsc
asier way to patch the location of user site packages?
I also had to do this for the Store install on Windows, and it's a
little bit of a hack... but maybe having an official recommendation
would help encourage distributors to use the mechanism?
Cheers,
Steve
___
want.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/
lly come around to the idea that UTF-8
is the only needed encoding, and I'm sure if it had existed when Windows
decided to support a universal character set, it would have been chosen.
But with what we have now, UTF-16-LE is not a good choice for anything
apart from compatibility with Wind
On 3/17/2021 7:34 PM, Ivan Pozdeev via Python-Dev wrote:
On 17.03.2021 20:30, Steve Dower wrote:
On 3/17/2021 8:00 AM, Michał Górny wrote:
How about writing paths as bytestrings in the long term? I think this
should eliminate the necessity of knowing the correct encoding for
the filesystem
The old rule is best: be strict in what you produce and liberal i what you
accept.
Kind regards,
Steve
On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman
wrote:
> On 4/12/2021 6:34 PM, Brett Cannon wrote:
>
> Had the sentences ended at "confusing" or said something like "
DEFAULT_TIMESTAMP?
Kind regards,
Steve
On Wed, Apr 14, 2021 at 8:03 PM wrote:
> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> Python-Dev mailing li
On Fri, Apr 16, 2021 at 7:15 PM Denis Kotov wrote:
> Ethan Furman wrote:
> > On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
> > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
> > > or read some articles ... otherwise I will need to spend too many time
> providing evidenc
On Thu, May 13, 2021 at 9:18 AM Mark Shannon wrote:
> Hi Terry,
>
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> >> As alway
rly say what the default
value is, either. So in all cases I have to read the docstring in
addition to the function signature.
Is the term you're looking for?
Perhaps or ?
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
ue that wouldn't also apply to any other kind of shared
sentinel.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.
On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano
wrote:
> Steve
> (one of the other ones)
>
We are all other Steves!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@py
ase.
All the other situations where we want arguments with unspecified
default values can use ..., and the few cases where ... is a valid value
(semantically, for the API, not syntactically) can spend the time
figuring out a different API design.
Cheers,
Steve
_
an use any version at all to build CPython and/or extension
modules.
Our official releases are always using relatively up-to-date compilers,
but provided the compatibility is maintained on Microsoft's side,
there's no need to worry about the specific versions.
Cheers,
Steve
On
obvious option), and use the complex
overrides in our own automated systems.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python
he importlib module's methods (but your *best* bet overall is to
run separate test suites in their own process so you can avoid the CWD
changes).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
seems intentional and not an error.
> >
> > Are you looking for a decorator for the whole Enum, or a way to mark
> individual *values* as masks?
>
> The decorator is for whole enum. The issue is not that some values are
> masks, but whether the absence of named bits
> cov
going to become significantly more attractive than
those two - even IronPython still lives on for embedding because it
works so well).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
ourself in a position where you have to justify it to someone
outside of the project (e.g. using work time for open source), hopefully
any core developer you've interacted with a bit will gladly write a
short endorsement for that.
Cheers,
Steve
p somehow. They can't, and
it's a little offensive to assume that your perceptions of the project will
somehow be revelatory. You describe real problems, but these problems are
well-known to the development team and you offer no new insights
nsible.
There's nothing wrong with the randomness from the function. It'll be
using the new API under the covers. So this is an enhancement, not a
security issue, and should only target 3.11.
Cheers,
Steve
___
Python-Dev mailing list -- python-d
m
to implement "standard" Python, having an explicit distinction here
would be helpful.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.
On 7/29/2021 6:17 PM, Barry Warsaw wrote:
On Jul 29, 2021, at 05:55, Steve Dower wrote:
Maybe we should have a "Type" other than Standards Track for PEPs that are
documenting implementation designs, rather than requirements for standardisation?
Wouldn’t Informational fill
On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum wrote:
> As it happens, I have a working prototype of lazy in marshaling that would
> work well for this.
>
> Nice to see you keep the time machine in working order ...
Kind regards,
Steve
__
On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings wrote:
> On 8/10/21 11:15 AM, Thomas Grainger wrote:
>
> Although the co_annoations code could intercept the NameError and replace
> return a ForwardRef object instead of the resolved name
>
>
> No, it should raise a NameError, just like any other P
hey may be
in email/issue archives), but since they exist, presumably they are
useful and viable _despite_ the bytecode varying between releases. This
suggests there's probably a better API we should add at the same time -
possibly some kind of unmarshalling or cloning-with-updates function?
Your inflated sense of your own significance is unfortunate, since it
appears to prohibit you from considering the possibility you might have
made a rather silly mistake here, and one which is calculated to move you
further away from your stated goals.
Kind regards,
Steve
On Tue, Aug 17, 2021
You forgot:
5. When I just don't damned well feel like it.
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:25 PM Brett Cannon wrote:
> I just wanted to apologize for any angst or noise my replies to Marco
> caused folks. I should have known that correcting Marco on how to address
I suspect it's the same motivation that makes us comment out a block of
code rather than deleting it, even though we know the VCS will let us
retirive it whenever we want. If I'm wrong it won't be fatal. Or surprising
;-)
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:53 PM Eric
t, and this one does not, so I stopped. (Might come back later
when I'm not trying to catch up on my weekend's email though.)
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
On 9/13/2021 8:12 PM, Ethan Furman wrote:
On 9/13/21 9:03 AM, Steve Dower wrote:
> You *are* allowed to put some (brief) details in the abstract. No
need to avoid spoilers ;)
>
> As it stands, "it is time" on its own is a really bad reason to
change anything. So you&
I understood that _iterables_ are required to have an __iter__ method, not
iterators.
Therefore, are we simply discussing whether all iterators should be
iterable? At the moment the CPython implementation does't require that
AFAIK.
regards
Steve
On Tue, Sep 14, 2021 at 8:39 PM Guido van R
to break any existing code, so
safe enough to enable if we can.
Agreed with Eric on the rest.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
nt with #2, there's no reliable way to detect whether
profile-guided optimisations were used on all CPython builds, which
means there'd be no reliable way to detect whether frozen modules are
going to be enabled by default or not. Adding a separate option handles
this case.
e? Would that defeat the performance improvement of
freezing? Is it just a terrible idea?
The filesystem access is what hurts the most, so yeah, that check won't
even be considered here without a manual opt-in (which is the option
Eric is dis
quot; option is totally
fine (and we'd add one to build.bat for this), but I still think it
needs to be discoverable later whether the frozen modules build option
was used or not, independent of other build options.
Cheers,
Steve
___
Python-Dev m
, and "except * E" looks like a binary operator
and/or grit on the screen.
Cheers,
Steve
[1]: Meaning to "give it a different meaning in particular context", not
_literally_ modify in any permanent sense.
___
Python-Dev mai
, virtually any alternative is going to be
more readable.
So enjoy bikeshedding, everyone :) Please don't break any of our code.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
st be a case of making the web installer publicly
available again. Chances are if you have the installer then it will still work.
We may also make just the compilers available in some other way. It looks like
the Windows Development Kits (previously Platform
ET Framework 3.5 SP1"
> is still available for download. It includes the command line compilers that
> are
> used with VS 2008. I have used to create extensions for Python 2.6 to 3.2.
> There is a later version of the SDK (for .NET
> 4.x) that includes the compilers from VS 201
> From: Terry Reedy
> On 3/6/2013 12:29 PM, Steve Dower wrote:
> > From: Case Van Horsen
>
> >> The "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1"
> >> is still available for download. It includes the command line
> >> compile
;m really looking forward to this.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
501 - 600 of 1536 matches
Mail list logo
