-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.05.15 um 09:59 schrieb Larry Hastings:
When you say branch testing, you mean running the buildbots
against it? Right now the UI for doing that is pretty clunky.
Kicking off a build against a server-side clone (iirc) requires
clicking
Am 02.05.15 um 21:57 schrieb Adam Bartoš:
Even if sys.stdin contained a file-like object with proper encoding
attribute, it wouldn't work since sys.stdin has to be instance of type
'file'. So the question is, whether it is possible to make a file instance
in Python that is also customizable so
Am 17.04.15 um 00:46 schrieb M.-A. Lemburg:
I had asked the PSF for a StartSSL certificate when the previous
certificate expired, and the PSF was not able to provide one. After
waiting several weeks for the PSF to provide the certificate, Kurt then
kindly went to Verisign.
When was that ? I
Am 05.04.15 um 06:43 schrieb Steve Dower:
Now I just have to find the time to learn how to use it...
I always sign with Kleopatra on Windows. It's really simple: just drag
all files you want to sign onto it, configure detached signatures, and
it will place the signature next to the original
Am 04.04.15 um 21:54 schrieb M.-A. Lemburg:
FWIW: The PSF mostly uses StartSSL nowadays and they also support code
signing certificates. Given that this option is a lot cheaper than
Verisign, I think we should switch, unless there are significant
reasons not to. We should revisit this in 2017.
Am 13.04.15 um 23:28 schrieb Zachary Ware:
In issue23903, I've created a script that will produce PC/python3.def
by scraping the header files in Include.
See my comment in the issue. Having a script to check is good; having it
generate the def file automatically is bad. It's typically the
Am 10.02.15 um 18:45 schrieb Steve Dower:
So I've enumerated the problems with PATH on Windows before (and my
subsequent dislike for modifying it through the installer)
It's quite comforting to hear this - I was arguing against that addition
for years (to the point of refusing to implement
Am 10.02.15 um 16:41 schrieb Steve Dower:
One of my main engineering concerns is lack of shared knowledge a.k.a. the
truck factor (not CPython specific, btw, just every project I work on).
Wrt. the installer, I think this is a lost cause. IIUC, you aren't
really getting familiar with msi.py,
Am 10.02.15 um 15:43 schrieb Paul Moore:
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com wrote:
I was also surprised as I was working on the installer, so +1 on changing
it.
On a procedural note, does this require a change to the PEP (assuming
it's generally acceptable)?
Am 04.01.15 00:34, schrieb Steve Dower:
so I'm keen to hear whatever feedback people have.
One issue that I always wanted to address is patch releases. There are
two aspects I dislike about the current implementation
a) an upgrade install first uninstalls the previous installation
(removing
Am 29.10.14 20:34, schrieb Glenn Linderman:
New package manager from M$... article here
http://www.neowin.net/news/windows-10-oneget-a-linux-style-package-management-framework.
I've looked at it, but only by reading its code, not trying it out.
Some notes.
First, what is Chocolatey? It's a
Most likely, OneGet won't replace pip/PyPI, any more than apt or yum
does; but it may be worth having Python itself available that way.
That might simply mean having someone package up Python and put it on
an appropriate server, or maybe python.org could end up hosting a
repo.
Python is
Am 24.09.14 14:34, schrieb Antoine Pitrou:
On Wed, 24 Sep 2014 17:12:35 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 24 Sep 2014 15:15, Tim Golden m...@timgolden.me.uk wrote:
On 23/09/2014 18:05, Steve Dower wrote:
I'm also considering/experimenting with installing into Program
Files by
Am 17.09.14 10:56, schrieb Steven D'Aprano:
On Wed, Sep 17, 2014 at 09:21:56AM +0900, Stephen J. Turnbull wrote:
Guido's mantra is something like Python's str doesn't contain
characters or even code points[1], it contains code units.
But is that true?
It used to be true, and stopped being
Am 24.08.14 03:11, schrieb Greg Ewing:
Isaac Morland wrote:
In HTML 5 it allows non-ASCII-compatible encodings as long as U+FEFF
(byte order mark) is used:
http://www.w3.org/TR/html-markup/syntax.html#encoding-declaration
Not sure about XML.
According to Appendix F here:
Am 22.08.14 01:56, schrieb Glenn Linderman:
0 and 47 are certainly originally derived from ASCII. However, there
could be lots of encodings that are not ASCII compatible (but in
practice, probably very few, since most encodings _are_ ASCII
compatible) that could be fit those constraints.
Am 18.08.14 08:45, schrieb Nick Coghlan:
It's certainly the one that has caused the most churn in CPython and
the standard library - the ripples still haven't entirely settled on
that front :)
For people porting their libraries and applications, the challenge is
often even bigger: they need to
Am 19.08.14 19:43, schrieb Ben Hoyt:
The official policy is that we want them [support for bytes paths in
stdlib functions] to go away, but reality so far has not budged. We will
continue to hold our breath though. :-)
Does that mean that new APIs should explicitly not support bytes? I'm
Am 21.08.14 17:44, schrieb Nick Coghlan:
I've now raised this issue with the infrastructure team. The current
hosting arrangements for bugs.python.org were put in place when the
PSF didn't have any on-call system administrators of its own, but now
that we do, it may be time to migrate that
Am 04.08.14 09:12, schrieb Larry Hastings:
It's my contention that nullable is the correct name. But I've been
asked to bring up the topic for discussion, to see if a consensus forms
around this or around some other name.
I have personally no problems with calling a type nullable even in
Am 12.07.14 17:19, schrieb Nick Coghlan:
Using the stable ABI for standard library extensions also serves to
decouple them further from the internal details of the CPython runtime,
making it more likely they will be able to run correctly on alternative
interpreters (since emulating or
Am 08.07.14 16:48, schrieb Guido van Rossum:
May the true owner of buildbot.python.org http://buildbot.python.org
stand up!
Well, I think that's me (atleast by my definition of true owner).
I requested that the machine be set up, and I deployed the software
that is running the service (it was
Am 01.07.14 09:44, schrieb Victor Stinner:
scandir(fd) must not close the file descriptor, it should be done by
the caller. Handling the lifetime of the file descriptor is a
difficult problem, it's better to let the user decide how to handle
it.
This is an open issue still: when is the file
* Is it a good strategy to ship to Python releases for every
single OpenSSL security release or is there a better way to
handle these 3rd party issues ?
At least for Windows, a new release certainly needs to be made.
It could be possible to produce MSI patch files, but this would
still
Am 23.06.14 22:04, schrieb Antoine Pitrou:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions
for Windows for more than a decade, and egg and msi distributions
for 8 years :-)
But without access to the VS 2008 compiler that is needed
Am 23.06.14 21:53, schrieb Ned Deily:
It does seem like a conundrum. As I have no deep Windows experience to
be able to have an appreciation of all of the technical issues involved,
I ask out of ignorance: would it be possible and desirable to provide a
transition period of n 2.7.x
Am 23.06.14 22:31, schrieb Barry Warsaw:
On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:
At the risk of getting Guido to post his slide again, I still think the
solution to the old compiler is to just roll a 2.8 with minimal changes.
No. It's not going to happen, for all the reasons
Am 23.06.14 22:31, schrieb Barry Warsaw:
Well, on reason is that you'd have to convince MvL or someone else to take
over the work that would require, but that's gotta be *much* lighter weight
than releasing a Python 2.8.
Just to point this out in a separate message: it will have to be
somebody
Am 17.06.14 18:41, schrieb Yates, Andy (CS Houston, TX):
Python Dev,
Andy here. I have a Windows product based on Python and I’m getting
hammered to release a version that includes the fix in OpenSSL 1.0.1h.
My product is built on a Windows system using Python installed from the
standard
Am 17.06.14 20:27, schrieb Steve Dower:
You'll only need to rebuild the _ssl and _hashlib extension modules
with the new OpenSSL version. The easiest way to do this is to build
from source (which has already been updated for 1.0.1h if you use the
externals scripts in Tools\buildbot), and you
Am 07.06.14 01:01, schrieb Steve Dower:
We keep the VS 2010 files around and make sure they keep working.
This is the biggest risk of the whole plan, but I believe that
there's enough of a gap between when VS 14 is planned to release
(which I know, but can't share) and when Python 3.5 is
Am 07.06.14 17:38, schrieb Steve Dower:
One more possible concern that I just thought of is the availability of
the build tools on Windows Vista and Windows 7 RTM (that is, without
SP1). I'd have to check, but I don't believe anything after VS 2012 is
supported on Vista and it's entirely
Am 10.06.14 18:30, schrieb Steve Dower:
I ran a quick test with profile-guided optimization (PGO, pronounced
pogo), which has supposedly been improved since VC9, and saw a very
unscientific 20% speed improvement on pybench.py and 10% size
reduction in python35.dll. I'm not sure what we used to
Am 06.06.14 17:41, schrieb Steve Dower:
Hi all
I would like to propose moving Python 3.5 to use Visual C++ 14.0 as
the main compiler.
This is fine with me, but I'm worried about the precise timing of doing
so. I assume that you would plan to do this moving before VC++ 14 is
actually
Am 06.06.14 19:31, schrieb Brian Curtin:
If that's a non-issue, or if we can actually drop XP support, I'm all for it.
Extended support ended in April of this year, so I think we should put
XP as unsupported for 3.5 in PEP 11 -
http://legacy.python.org/dev/peps/pep-0011/
I seem to
Am 06.06.14 20:25, schrieb Brian Curtin:
We're going to have to change it at some point, otherwise we're going
to have people in 2018 scrambling to find VS2008, which will be 35
versions too old by then.
Not sure whether you picked 2018 deliberately: extended support for
VS2008 Professional
Am 06.06.14 21:20, schrieb Martin v. Löwis:
2. what is the risk of installing a beta compiler on what might
otherwise be a production developer system? In particular, could
it interfere with other VS installations, and could it require a
complete system reinstall when the final
Am 06.06.14 22:13, schrieb Paul Moore:
From http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs
Currently, Visual Studio 14 CTPs have known compatibility issues
with previous releases of Visual Studio and should not be installed
side-by-side on the same computer.
I also
Am 01.06.14 00:21, schrieb Terry Reedy:
Responding today, I cautioned that clean-up only patches, such as she
apparently would like to start with, are not in favor.
I would not say that. I recall that I asked Gregor to make a number of
style changes before he submitted the code, and
Am 31.05.14 05:32, schrieb Terry Reedy:
I have two areas of questions about updating turtle.py. First the module
itself, then a turtle tracker issue versus code cleanup policies.
A. Unlike most stdlib modules, turtle is copyrighted and licensed by an
individual.
'''
# turtle.py: a Tkinter
Am 31.05.14 10:09, schrieb Stephen J. Turnbull:
AFAICT Python policy is that someone should ask Gregor (a precedent is
the Fredrik Lundh/ElementTree case). AIUI, there's been a five-year
span since Gregor's been active, so I would think it's basically a
matter of courtesy. Most likely he's
Am 24.05.14 12:15, schrieb Herbert Griebel:
Found the issue. To reproduce the problem install Python 3.4.0, then
rename the install folder (e.g. C:\Python34 to C:\Python34x) and install
Python 3.4.1.
Please understand that installation of 3.4.1 attempts uninstallation of
3.4 first. Without
Am 15.05.14 16:20, schrieb Skip Montanaro:
On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou solip...@pitrou.net wrote:
We already have such buildbots, they are in the unstable category.
You can browse through existing buildbots here:
https://www.python.org/dev/buildbot/
I can't see how to
Am 14.05.14 16:28, schrieb Barry Warsaw:
On May 14, 2014, at 02:20 PM, Brett Cannon wrote:
Do we want an official policy written down in a PEP (yes, I can write it)?
Should I keep closing these patches and saying that we are not adding
support for new operating systems and be hand-wavy about
Am 08.05.14 18:59, schrieb Brian Curtin:
This is mostly a question for Martin, but perhaps someone else would also
know.
I'm trying to build the 2.7 installers so I can backport the path
option from 3.3, but I can't seem to figure out which version of Tix
is necessary to have a complete
Am 17.04.14 20:47, schrieb Brett Cannon:
Because people keep bringing it up, below is the results of hacking up
the interpreter to include a sys.path entry for ./python35.zip instead
of hard-coding to /usr/lib/python35.zip and simply zipped up Lib/
recursively. TL;DR, zipimport performance no
Am 17.04.14 20:47, schrieb Brett Cannon:
Because people keep bringing it up, below is the results of hacking up
the interpreter to include a sys.path entry for ./python35.zip instead
of hard-coding to /usr/lib/python35.zip and simply zipped up Lib/
recursively. TL;DR, zipimport performance no
Am 14.04.14 23:51, schrieb Brett Cannon:
It was realized during PyCon that since we are freezing importlib we
could now consider freezing all the modules to cut out having to stat or
read them from disk.
[...]
Thoughts?
They still get read from disk, except that it is the operating system
Am 10.04.14 03:22, schrieb Benjamin Peterson:
We'll keep doing what we're currently doing for another year, making
normal bug fix releases with installers. After that, we _won't_ close
2.7 to normal bug fixes as is currently implied by the release schedule.
After thinking about this plan, I
Am 13.04.14 03:07, schrieb Benjamin Peterson:
On Sat, Apr 12, 2014, at 17:30, Stephen J. Turnbull wrote:
I apologize for the tone. I need to go *right* now, and can't fix
that. Really, I'm sympathetic and my goal is not just to defend
python-dev, but to help you get the reviews your work
Am 13.04.14 08:36, schrieb Stephen J. Turnbull:
I admit the tone was biased toward nagging or blaming the victim,
and again I apologize for causing misunderstanding. Nikolaus isn't
wrong for posting here. My claim is that in current circumstances,
core-mentorship would be a more *effective*
Am 10.04.14 15:41, schrieb Paul Moore:
Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
with the Windows installers (1.0.1e in Python 3.4.0) should we be
releasing updated installers?
As others have said: certainly, and only for 3.4.0 (i.e. 2.7 in
particular is not affected
Am 13.04.14 21:41, schrieb Steve Dower:
I'm willing to embark on migrating the entire installer to WiX, which
doesn't directly fix any particular issue, but could significantly
reduce the overhead of building and maintaining the Windows installers.
I somewhat doubt that it could reduce the
Am 13.04.14 22:02, schrieb Steve Dower:
I replied to the other email before I saw this one.
Same here :-)
Consider this my self-nomination to take over, pending a quick email to
Microsoft's lawyers to make sure it's okay (it should be, but IANAL and
they wrote the policy).
My plan would
Am 01.04.14 13:45, schrieb Nick Coghlan:
Interesting to see the UCS2 removal there for 3.3. That's a genuine
removal from the public ABI as part of PEP 393. I guess the reason
nobody complained is because most 3.2 Linux builds used the UCS4 ABI
instead, and the stable ABI hadn't seen broad
I have created a buildbot configuration to test freeze. At the moment,
it has only one builder:
http://buildbot.python.org/all/waterfall?show=AMD64%20Ubuntu%20LTS%20Freeze%203.x
which currently fails as freeze doesn't actually work.
The test itself works by first building Python in release
[Assuming you are talking about PyUnicode_FromFormatV]
%s is a string.
No. %s is a char*; C does not have a string type.
The string behind the pointer should be UTF-8 encoded;
other encodings are tolerated through the replace error
handler.
%U is unicode?
No. This is a PyObject* whose Python
Am 22.03.14 22:03, schrieb Benjamin Peterson:
On Sat, Mar 22, 2014, at 11:10, Antoine Pitrou wrote:
Hello,
I've created the 3.4 category in the buildbots setup:
http://buildbot.python.org/all/waterfall?category=3.4.stable
I've also retired 3.2 and 3.3 buildbots. Someone will have to
Am 25.03.14 14:47, schrieb Nick Coghlan:
The PEP says to sync with Python 3, and that has full cross platform
support. The Linux focus just comes from the fact that Linux is where
the problem is most evident.
However, it fails to address a critical detail: the upcoming maintenance
end for 2.7.
Am 23.03.14 08:07, schrieb Nick Coghlan:
Several significant changes in this revision:
- scope narrowed to just Python 2.7 plus permission for commercial
redistributors to use the same strategy in their long term support
releases
Thanks; the rationale is now much clearer, and also indicates
Am 23.03.14 17:22, schrieb Guido van Rossum:
At Dropbox I work with a large group of very capable developers on
several large code bases that are currently in 2.7. We are constantly
changing our code to make it more secure (there are several teams
specifically in charge of that). And yet
Am 22.03.14 22:17, schrieb Cory Benfield:
I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7
is a security liability, any it becomes nothing short of irresponsible to
use Python 2.7 for any form of networking code that hits the open
internet.
Agreed (although this might
Am 22.03.14 22:11, schrieb Nick Coghlan:
Title: Network Security Enhancement Exception for All Branches
I'm -0 on the general idea, and -1 on the inclusion of the 2.7 branch
into the policy.
The PEP trades security concerns against stability and maintainability.
I see a maintenance threat
Am 22.03.14 23:05, schrieb Donald Stufft:
I think the pep doesn't mandate that someone does. It still requires someone
to care enough to actually write the patch. It just allows such a patch to be
merged.
Does it actually? Unfortunately, I never got around to writing the PEP
on
Am 22.03.14 23:21, schrieb Donald Stufft:
Just use Python 3.4 ignores the reality of production software. I wish it
were that simple because I love 3.4
But I think so does the PEP (i.e. ignore the reality of production
software). The risk of breaking existing installations (which might
not be
Am 22.03.14 23:33, schrieb Nick Coghlan:
Hard to maintain legacy software is a fact of life, and way too much
of it is exposed to the public internet. This PEP is about doing what
we can to mitigate the damage caused both by other people's mistakes,
and also the inherent challenges of
Am 22.03.14 23:39, schrieb Ned Deily:
Regarding the python.org binary installers, I think past practice has
been for us to update third-party libraries as necessary in maintenance
releases when there is good cause and with the concurrence of the
release manager, so I don't see this as a big
Am 23.03.14 00:02, schrieb Benjamin Peterson:
As (I believe) previously discussed and documented in PEP 373, this date
currently will be May 2015.
Ah! Thanks for reminding me. I think PEP 466 then needs to take a
position on that, as well. By the past schedule, this probably means
two more bug
Am 23.03.14 01:15, schrieb Christian Heimes:
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
cryptography-related, but that shouldn't make a difference.
(for example the
Am 17.03.14 22:10, schrieb Jurko Gospodnetić:
Fixing
this required manually cleaning up leftover CPython 3.4.0rc3 windows
installer registry entries. Note that the issue could not be fixed by
using the CPython 3.4.0rc3 installer as it failed due to the same problem.
Did you try the 3.4.0rc3
Am 17.03.14 16:18, schrieb Benjamin Peterson:
On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:
On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
victor.stin...@gmail.comwrote:
Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
accept security fixes, right?
Am 14.03.14 15:04, schrieb Barry Warsaw:
On Mar 14, 2014, at 04:48 PM, Nick Coghlan wrote:
I opened https://github.com/python/pythondotorg/issues/297 to ask for
an ETA on when we can expect them to be fully integrated.
Thanks Nick. On the bug I suggest creating peps.python.org.
And I
Am 12.03.14 04:58, schrieb Chris Angelico:
On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman et...@stoneleaf.us wrote:
I sure hope this is accepted. I could have used it at least a half-dozen
times in the last week -- which is more often than I would have used the
ternary-if! :)
Where do we
Am 10.03.14 14:03, schrieb Jurko Gospodnetić:
Is this as issue or desired behaviour?
See my response in the tracker. It's desired by Microsoft.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Am 10.03.14 18:01, schrieb Tres Seaver:
On 03/10/2014 12:49 PM, Brett Cannon wrote:
I think it got lost in email threading, but Barry pointed out that
Guido famously hates double digit version numbers (as do I, probably
partially because he does after all these years =).
Guido hates them
Am 05.02.14 17:04, schrieb Georg Brandl:
Mostly unrelated question while seeing the char * here: do we (or do we
want to) support non-ASCII names for functions implemented in C?
I didn't try, but I think it should work.
methodobject.c:meth_get__name__ uses PyUnicode_FromString, which in turn
Am 03.02.14 15:43, schrieb Larry Hastings:
A: We create a PyMethodDefEx structure with an extra field: const char
*signature. We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
the flags, indicating that this is an extended structure. When
iterating over the PyMethodDefs, we know how
Am 29.01.14 03:46, schrieb Larry Hastings:
So this would be a new public ABI function?
Correct.
Would it be 100% new code, or would you need to refactor code internally
to achieve it?
See the patch - it's new code.
Also, just curious: what is typeslots.h used for? I tried searching for
I'd like to resolve a long-standing issue of the stable ABI in 3.4:
http://bugs.python.org/issue17162
The issue is that, since PyTypeObject is opaque, module authors cannot
get at tp_free, which they may need to in order to implement tp_dealloc
properly.
Rather than providing the proposed
I've debugged this a little bit. I couldn't originally see where the
problem is, since I expected that the code dealing with shared
references shouldn't ever trigger - none of the tuples in the example
are actually shared (i.e. they all have a ref-count of 1, except for
the outer list, which is
Am 23.01.14 07:45, schrieb Scott Dial:
Anecdotally, I already know of a system at work that is using HTTPS
purely for encryption, because the authentication is done in-band. So, a
self-signed cert was wholly sufficient. The management tools use a
RESTful interface over HTTPS for control, but
Am 12.01.14 18:39, schrieb Nachshon David Armon:
I propose that this new version of python use the python 3 unicode model.
As the version of python will be fully compatible with both python 2 and
with python 3 but NOT necsesarily with all existing code in either. It is
designed as a porting
Am 08.01.14 16:03, schrieb Nick Coghlan:
On 9 January 2014 00:43, Bob Hanson d2mp...@newsguy.com wrote:
When I read this comment of yours, Guido, I immediately started
wondering about this. You may well be right -- indeed, I have a
very old install (c.2007) which has not been updated (other
Am 06.01.14 17:26, schrieb Michael Urman:
Here's some more guesswork. Does it seem possible that msiexec is
trying to verify the revocation status of the certificate used to sign
the python .msi file? Per
http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx
Right. But even latin-1, or better, cp1252 (on windows) does not solve it
because these have undefined
code points.
That's not true. latin-1 does not have undefined code points.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Am 07.01.14 15:08, schrieb Daniel Holth:
Isn't it true that if you have bytes 127 or surrogate escapes then
encoding to latin1 is no longer as fast as memcpy?
You mean decoding from latin1 (i.e. bytes to string)?
No, the opposite is true. It couldn't use memcpy before, but does now
(see
Am 31.12.13 01:24, schrieb Chris Angelico:
Does Buildbot retain a constant TCP socket to its server?
In short: yes. A little bit longer: It uses the Twisted
PerspectiveBroker protocol. That has nearly-transparent
reconnects (but as your case shows, not fully transparent),
and does regular ping
Am 31.12.13 07:12, schrieb Tim Peters:
[Dan Stromberg]
I keep hearing naysayers, nay saying about Python 3.x.
Here's a 9 question, multiple choice survey I put together about
Python 2.x use vs Python 3.x use.
I'd be very pleased if you could take 5 or 10 minutes to fill it out.
If you
Am 31.12.13 11:04, schrieb Steven D'Aprano:
On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg drsali...@gmail.com wrote:
So far the results are looking good for 3.x.
Python-dev probably is a bit special.
Why? Most Python-Dev
Am 05.12.13 02:04, schrieb Vajrasky Kok:
Cool. What about Linux/Unix/BSD with root account? If we have
something similar, I may plan to write unit test for spwd module.
Can you please phrase your question more explicit? What is it that
you want to be done before writing unit tests for the spwd
Am 05.12.13 16:21, schrieb Vajrasky Kok:
On Thu, Dec 5, 2013 at 11:06 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Can you please phrase your question more explicit? What is it that
you want to be done before writing unit tests for the spwd module?
I am asking buildbot of Linux/Unix/BSD
Am 05.12.13 16:31, schrieb Chris Angelico:
Ah. I don't think we have one. If somebody would want to donate one, I
suggest to run it in a VM, to reduce the (valid) security concerns that
Guido has voiced. If a snapshot of the VM is made, it would be easy to
restore in case a commit performs
Am 22.11.13 01:58, schrieb Steve Dower:
I'm happy to work on a PEP and changes for what I described above, if
there's enough interest? I can also update distutils to detect and
build with any available compiler, though this may be more of a
feature than we'd want for 2.7 at this point.
I
Am 22.11.13 10:00, schrieb Richard Tew:
That there are people who would consider using the trademark to force
us to change the name we've been using without harm for 14 years,
worries me. It's one thing to perhaps use it to stop someone scamming
Python users, and another to suggest using it
Am 22.11.13 17:54, schrieb Christian Tismer:
The discussion is over, but I cannot let this comment go through without
citing my original question, again:
My question
---
I have created a very clean Python 2.7.6+ based CPython with the
Stackless
additions, that compiles with VS
Am 22.11.13 19:10, schrieb Steve Dower:
I'd really want to update distutils.msvc9compiler to detect later
versions as well, since that would make 'pip install' work properly
for a large (majority?) of users for a large (majority?) of packages
with extension modules. Some may consider this
Am 20.11.13 06:18, schrieb Tim Peters:
BTW, I'm not a web guy: in what way is HTTP chunked transfer mode
viewed as being flawed? Everything I ever read about it seemed to
think it was A Good Idea.
It just didn't work for some time, see e.g.
http://bugs.python.org/issue1486335
Am 20.11.13 17:04, schrieb Eric V. Smith:
I think the confusion comes from the difference between what NTFS can do
and what the Win32 (or whatever it's now called) layer allows you to do.
Rumor has it that the old Posix subsystem allowed NTFS to create 2 files
in the same directory that
Am 19.11.13 20:59, schrieb Antoine Pitrou:
That's integrated to the built-in buffering. It's not really an
additional constraint: the frame sizes simply dictate how buffering
happens in practice. The main point of framing is to *simplify* the
buffering logic (of course, the old buffering logic
Am 19.11.13 21:28, schrieb Antoine Pitrou:
Well, unless you propose a patch before Saturday, I will happily ignore
your proposal.
See
http://bugs.python.org/file32709/framing.diff
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
1 - 100 of 4853 matches
Mail list logo
