Hi,
I don't know anyone building Python without Unicode. I would prefer to
modify configure to raise an error, and drop #ifdef in the code. (Stop
supporting building Python 2 without Unicode.)
Building Python 2 without Unicode support is not an innocent change.
Python is moving strongly to Unicod
2014-06-24 13:04 GMT+02:00 Skip Montanaro :
> I can't see any reason to make a backwards-incompatible change to
> Python 2 to only support Unicode. You're bound to break somebody's
> setup. Wouldn't it be better to fix bugs as Serhiy has done?
According to the long list of issues, I don't think th
2014-06-25 14:58 GMT+02:00 Serhiy Storchaka :
> 24.06.14 22:54, Ned Deily написав(ла):
>
>> Benefit:
>> - Fixes documented feature that may be of benefit to users of Python in
>> applications with very limited memory available, although there aren't
>> any open issues from users requesting this (AF
Hi,
You wrote a great PEP Ben, thanks :-) But it's now time for comments!
> But the underlying system calls -- ``FindFirstFile`` /
> ``FindNextFile`` on Windows and ``readdir`` on Linux and OS X --
What about FreeBSD, OpenBSD, NetBSD, Solaris, etc. They don't provide readdir?
You should add a
2014-06-26 13:04 GMT+02:00 Antoine Pitrou :
> For the same reason, I agree with Victor that we should ditch the
> threading-disabled builds. It's too much of a hassle for no actual,
> practical benefit. People who want a threadless unicodeless Python can
> install Python 1.5.2 for all I care.
By t
2014-07-01 4:04 GMT+02:00 Glenn Linderman :
>> +0 for stat fields to be None on all platforms unless ensure_lstat=True.
>
> This won't work well if lstat info is only needed for some entries. Is
> that a common use-case? It was mentioned earlier in the thread.
>
> If it is, use ensure_lstat=False,
Hi,
IMO we must decide if scandir() must support or not file descriptor.
It's an important decision which has an important impact on the API.
To support scandir(fd), the minimum is to store dir_fd in DirEntry:
dir_fd would be None for scandir(str).
scandir(fd) must not close the file descripto
Hi,
@Ben: it's time to update your PEP to complete it with this
discussion! IMO DirEntry must be as simple as possible and portable:
- os.scandir(str)
- DirEntry.lstat_result object only available on Windows, same result
than os.lstat()
- DirEntry.fullname(): os.path.join(directory, DirEntry.name
2014-07-01 14:26 GMT+02:00 Ben Hoyt :
> Thanks, Victor.
>
> I don't have any experience with dir_fd handling, so unfortunately
> can't really comment here.
>
> What advantages does it bring? I notice that even os.listdir() on
> Python 3.4 doesn't have anything related to file descriptors, so I'd
>
2014-07-01 15:00 GMT+02:00 Ben Hoyt :
> (a) it doesn't call stat for you (on POSIX), so you have to check an
> attribute and call scandir manually if you need it,
Yes, and that's something common when you use the os module. For
example, don't try to call os.fork(), os.getgid() or os.fchmod() on
Wi
2014-07-02 12:51 GMT+02:00 Charles-François Natali :
> I don't think we should support it: it's way too complicated to use,
> error-prone, and leads to messy APIs.
Can you please elaborate? Which kind of issue do you see? Handling the
lifetime of the directory file descriptor?
You don't like the
Hi,
2014-07-08 15:52 GMT+02:00 Ben Hoyt :
> After some very good python-dev feedback on my first version of PEP
> 471, I've updated the PEP to clarify a few things and added various
> "Rejected ideas" subsections. Here's a link to the new version (I've
> also copied the full text below):
Thanks,
Le mardi 8 juillet 2014, Ben Hoyt a écrit :
>
> > It is not clear to me which methods share the cache.
> >
> > On UNIX, is_dir() and is_file() call os.stat(); whereas lstat() and
> > is_symlink() call os.lstat().
> >
> > If os.stat() says that the file is not a symlink, I guess that you can
> > u
2014-07-08 22:09 GMT+02:00 Ben Hoyt :
>>> I think you're misunderstanding is_dir() and is_file(), as these don't
>>> actually call os.stat(). All DirEntry methods either call nothing or
>>> os.lstat() to get the stat info on the entry itself (not the
>>> destination of the symlink).
>>
>>
>> Oh. Ex
2014-07-09 15:12 GMT+02:00 Ben Hoyt :
>> Ok, so it means that your example grouping files per type, files and
>> directories, is also wrong. Or at least, it behaves differently than
>> os.walk(). You should put symbolic links to directories in the "dirs"
>> list too.
>>
>> if entry.is_dir(): # is
2014-07-09 21:59 GMT+02:00 Ben Hoyt :
> Other python-devers, please chime in with your thoughts or votes.
Sorry, I didn't follow the whole discussion. IMO DirEntry must use
methods and you should not expose nor document which infos are already
provided by the OS or not. DirEntry should be a best-e
2014-07-09 22:44 GMT+02:00 Ethan Furman :
> On 07/09/2014 01:24 PM, Victor Stinner wrote:
>> Sorry, I didn't follow the whole discussion. IMO DirEntry must use
>> methods and you should not expose nor document which infos are already
>> provided by the OS or not. DirEnt
2014-07-09 17:29 GMT+02:00 Ben Hoyt :
>> Would this not "break" the tree size script being discussed in the
>> other thread, as it would follow links and include linked directories
>> in the "size" of the tree?
The get_tree_size() function in the PEP would use: "if not
entry.is_symlink() and entry
2014-07-09 17:26 GMT+02:00 Paul Moore :
> On 9 July 2014 16:05, Victor Stinner wrote:
>> The PEP says that DirEntry should mimic pathlib.Path, so I think that
>> DirEntry.is_dir() should work as os.path.isir(): if the entry is a
>> symbolic link, you should follow the symlink
Oh, since I'm proposing to add a new stat() method to DirEntry, we can
optimize it. stat() can reuse lstat() result if the file is not a
symlink. It simplifies is_dir().
New pseudo-code:
---
class DirEntry:
def __init__(self, path, name, lstat=None, d_type=None):
self.name = name
2014-07-10 9:04 GMT+02:00 Paul Moore :
> As someone (Tim?) pointed out later in the thread,
> FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor
> do the dirent entries on Unix). So whether or not it's "natural", the
> "free" functionality provided by the OS is that of lstat, no
The PEP has been rejected, but the MappingProxyType is now public:
$ ./python
Python 3.5.0a0 (default:5af54ed3af02, Jul 12 2014, 03:13:04)
>>> d={1:2}
>>> import types
>>> d = types.MappingProxyType(d)
>>> d
mappingproxy({1: 2})
>>> d[1]
2
>>> d[1] = 3
Traceback (most recent call last):
File "",
2014-07-14 2:33 GMT+02:00 Ben Hoyt :
> If we go with Victor's link-following .is_dir() and .is_file(), then
> we probably need to add his suggestion of a follow_symlinks=False
> parameter (defaults to True). Either that or you have to say
> "stat.S_ISDIR(entry.lstat().st_mode)" instead, which is a
2014-07-14 4:17 GMT+02:00 Nick Coghlan :
> Or the ever popular symlink to "." (or a directory higher in the tree).
"." and ".." are explicitly ignored by os.listdir() an os.scandir().
> I think os.walk() is a good source of inspiration here: call the flag
> "followlink" and default it to False.
2014-07-14 6:52 GMT+02:00 Ethan Furman :
> We shoIf you put the option on scandir(), you uld have a flag for that, and
> default it to False:
>
> scandir(path, *, followlinks=False, info=None, onerror=None)
What happens to name and full_name with followlinks=True? Do they
contain the name in th
Le mardi 15 juillet 2014, Ben Hoyt a écrit :
>
>
> Victor had one other question:
>
> > What happens to name and full_name with followlinks=True?
> > Do they contain the name in the directory (name of the symlink)
> > or name of the linked file?
>
> I would say they should contain the name and ful
Hi,
2014-07-20 18:50 GMT+02:00 Antoine Pitrou :
> Have you tried modifying importlib's _bootstrap.py to use scandir() instead
> of listdir() + stat()?
IMO the current os.scandir() API does not fit importlib requirements.
importlib usually wants fresh data, whereas DirEntry cache cannot be
invalid
Hi,
2014-07-21 21:26 GMT+02:00 matsjoyce :
> Sorry about being a bit late on this front (just 5 years...), but I've
> extended tav's jail to module level, and added the niceties. It's goal is
> similar to that of rexec, stopping IO, but not crashes. It is currently at
> https://github.com/matsjoyc
Hi,
I asked privately Guido van Rossum if I can be the BDFL-delegate for
the PEP 471 and he agreed. I accept the latest version of the PEP:
http://legacy.python.org/dev/peps/pep-0471/
I consider that the PEP 471 "scandir" was discussed enough to collect
all possible options (variations of th
2014-07-21 18:48 GMT+02:00 Ben Hoyt :
>> By the way, DirEntry constructor is not documented in the PEP. Should
>> we document it? It might be a way to "invalidate the cache":
>
> I would prefer not to, just to keep things simple. Similar to creating
> os.stat_result() objects ... you can kind of do
Modify os.listdir() to use os.scandir() is not part of the PEP, you should
not do that. If you worry about performances, try to implement my free list
idea.
You may modify the C code of listdir() to share as much code as possible. I
mean you can implement your idea in C.
Victor
__
2014-07-22 17:52 GMT+02:00 Ben Hoyt :
> However, given that we have to support this for listdir() anyway, I
> think it's worth reconsidering whether scandir()'s directory argument
> can be an integer FD. Given that listdir() already supports it, it
> will almost certainly be asked for later anyway
2014-07-22 4:27 GMT+02:00 Ben Hoyt :
>> The PEP is accepted.
>
> Superb. Could you please update the PEP with the Resolution and
> BDFL-Delegate fields?
Done.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
Hi,
You should read the Python Developer Guide:
https://docs.python.org/devguide/
You can also join the core mentorship mailing list:
http://pythonmentors.com/
Welcome!
Victor
2014-07-29 17:11 GMT+02:00 agrim khanna :
> Respected Sir,
>
> I am Agrim Khanna, undergraduate student in IIIT All
2014-08-11 19:42 GMT+02:00 matsjoyce :
> Yup, I read that post. However, those specific issues do not exist in my
> module, as there is a module whitelist, and a method whitelist. Builtins are
> now proxied, and all types going in to functions are checked for
> modification. There maybe some holes
Hi,
I heard that PyPy sandbox cannot be used out of the box. You have to write
a policy to allow syscalls. The complexity is moved to this policy which is
very hard to write, especially if you only use whitelists.
Correct me if I'm wrong. To be honest, I never take a look at this sandbox.
Victor
Hi,
IMO we should not document enum types because Python implementations other
than CPython may want to implement them differently (ex: not all Python
implementations have an enum module currently). By experience, exposing too
many things in the public API becomes a problem later when you want to
2014-08-15 21:54 GMT+02:00 Serhiy Storchaka :
> 15.08.14 08:50, Nick Coghlan написав(ла):
>> * add bytes.zeros() and bytearray.zeros() as a replacement
>
> b'\0' * n and bytearray(b'\0') * n look good replacements to me. No need to
> learn new method. And it works right now.
FYI there is a pending
2014-08-15 7:50 GMT+02:00 Nick Coghlan :
> As far as I am aware, that last item poses the only open question,
> with the alternative being to add an "iterbytes" builtin (...)
Do you have examples of use cases for a builtin function? I only found
5 usages of bytes((byte,)) constructor in the standa
HTML version:
http://legacy.python.org/dev/peps/pep-0475/
PEP: 475
Title: Retry system calls failing with EINTR
Version: $Revision$
Last-Modified: $Date$
Author: Charles-François Natali , Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-July-2014
Python
Hi,
Sorry but I don't understand your remark. What is your problem with
retrying syscall on EINTR? Can you please elaborate? What do you mean by
"get wrong"?
Victor
Le dimanche 31 août 2014, Marko Rauhamaa a écrit :
> Victor Stinner >:
>
> > Proposition
>
Le dimanche 31 août 2014, Marko Rauhamaa a écrit :
> Victor Stinner >:
>
> > Sorry but I don't understand your remark. What is your problem with
> > retrying syscall on EINTR?
>
> The application will often want the EINTR return (exception) instead of
> ha
Le 1 sept. 2014 00:04, "Marko Rauhamaa" a écrit :
>
> Victor Stinner :
>
> > But I don't get you point. How does this PEP make the situation worse?
>
> Did I say it would? I just wanted to make sure the system call
> resumption doesn't become mandato
Le 1 sept. 2014 00:17, "Marko Rauhamaa" a écrit :
> If a signal is received when read() or write() has completed its task
> partially (> 0 bytes), no EINTR is returned but the partial count.
> Obviously, Python should take that possibility into account so that
> raising an exception in the signal
No, it's the opposite. The PEP doesn't change the default behaviour of
SIGINT: CTRL+C always interrupt the program.
Victor
Le 1 sept. 2014 08:12, "Paul Moore" a écrit :
> On 31 August 2014 22:38, Victor Stinner wrote:
> > This case is described as the use
Le 1 sept. 2014 02:40, "Greg Ewing" a écrit :
>
> Victor Stinner wrote:
>>
>> As written in the PEP, if you want to be notified of the signal, set a
signal handler which raises an exception.
>
>
> I'm not convinced that this covers all possible use
Hi,
My bashrc sets MAKEFLAGS to -j9 and Python compilation works fine on Fedora
20 with GNU make and GCC. My computer has 8 cores (4 physical with hyper
threading).
It looks like your compiler is Clang. What is your OS and OS version?
Can you try to run make in verbose mode and attach the full l
2014-09-02 23:02 GMT+02:00 Matthew Woodcraft :
> I think people who use sleep() in their programs could benefit from not
> having to worry about EINTR as much as anyone else.
The behaviour of time.sleep() is worse than what I expected. On UNIX,
if select() fails with EINTR, time.sleep() calls PyE
2014-09-02 23:03 GMT+02:00 Matthew Woodcraft :
> In any case I think PEP 475 should be explaining what is going to happen
> to signal.siginterrupt(). Will setting flag=True be supported?
I first proposed to deprecate the function, but Charles-François
thinks that it's unrelated to the PEP (it can
Hi,
I'm using Python buildbots to ensure that my changes don't fail on
some platform. It's important for changes close to the operation
system. The problem is that many buildbots are ill.
Before, only a few buildbots had sporadic failures. Now most buildbots
are always fail (are red).
Here is an
2014-09-03 21:26 GMT+02:00 Christian Heimes :
> On 03.09.2014 19:54, Guido van Rossum wrote:
> I'm +1 for Python 3.5 but -1 for Python 2.7.
>
> The SSLContext backport will landed in Python 2.7.9 (to be released). No
> Python 2 user is familiar with the feature yet. But more importantly:
> None of
2014-09-03 0:13 GMT+02:00 Victor Stinner :
> AMD64 OpenIndiana 3.x: a lot of tests fail with OSError(12, "Not
> enough space") or MemoryError. It's probably on issue on the host.
>
> x86 OpenIndiana 3.x: MemoryError. TestReadline.test_init() also fails.
I sent an e
Why not quoting the whole sentence?
Victor
Le 19 sept. 2014 03:31, "Ben Hoyt" a écrit :
> I was emailing someone today about implementing something (for PEP
> 471, as it happens) and wanted to link to the Zen of Python [1] and
> note a particular clause (in this case "If the implementation is ha
Someone broke test_pydoc. Example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.4/builds/481/steps/test/logs/stdio
Victor
2014-09-22 16:15 GMT+02:00 Larry Hastings :
>
>
> On behalf of the Python development community and the Python 3.4 release
> team, I'm chuffed to announc
2014-09-23 2:22 GMT+02:00 Donald Stufft :
<> I think we need a Python 3.5 Release Schedule PEP.
>>
>> Just checked it in as PEP 478. It should show up here in a few minutes:
>>
>> http://legacy.python.org/dev/peps/pep-0478/
>> Comments?
>
> It says 3.4.0 all through it.
It was too distrubing to r
Most Windows setup are desktop configured with a single user. I would not
be shocked if pip installs modules only for the current user by default.
Maybe it could be an option in Python installer (pip system wide or user).
Victor
Le mercredi 24 septembre 2014, Paul Moore a écrit :
> On 24 Septem
Hi,
I prefer "bytes-like" than "buffer protocol". By the way, is there a
documentation in Python doc which explains "bytes-like" and maybe list most
compatible types?
I'm not sure that the term has an unique definition. In some parts of
Python, I saw explicit checks on the type: bytes or bytearra
Hi,
2014-10-06 18:08 GMT+02:00 Ethan Furman :
> With the incredibly long life span of 2.7, which bugs should we *not* fix?
I started a list of Python 2 bugs that will not be fixed:
http://haypo-notes.readthedocs.org/python.html#bugs-that-won-t-be-fixed-in-python-2-anymore
It *is* possible to fix
2014-10-08 10:57 GMT+02:00 Larry Hastings :
> You can download it here:
>
> https://www.python.org/download/releases/3.4.2
This page redirect me to
https://www.python.org/download/releases/3.4.1 Maybe some web servers
of the CDN don't contain the latest version. I guess that the issue
will quickl
Hi,
You can develop a codec and plug it into Python 3.4 right now using
codecs.register().
It's difficult to decide if a codec is important enough to be added to Python.
When you say "IMAP4", do you mean any IMAP4 server? Do you have a list
of server vendors known to use the encoding mUTF-7? Is
2014-10-10 1:33 GMT+02:00 Jesus Cea :
> The purpose of these modifications is to correct the following
>problems with UTF-7:
If you need performances, I would be interested to see if it would be
possible to reuse the C codec for UTF-7 to share as much code as
possible.
What is the current beh
Hi,
Windows is not the primary target of Python developers, probably
because most of them work on Linux. Official Python binaries are
currently built by Microsoft Visual Studio. Even if Python developers
get free licenses thanks for Microsoft, I would prefer to use an open
source compiler if it wo
2014-10-10 2:34 GMT+02:00 Jesus Cea :
>> What is the current behaviour of imaplib in Python 3.4 with non-ASCII
>> characters in mailbox names?
>
> It breaks. Crash & burn.
Oh ok. So in short, imaplib doesn't work on Python 3: it's a bug and
it must be fixed. I agree that a new codec is good idea a
2014-10-10 2:52 GMT+02:00 Jesus Cea :
> "Yes, Python 2 is broken, the real deal is Python 3"? :).
For Unicode, my favorite answer is "it's time to upgrade! Python 3 has
a much better Unicode support." and not fix the issue on Python 2.7.
I don't want to open the can of worm "unicode" in Python 2.
2014-10-10 11:18 GMT+02:00 Sturla Molden :
> If you build Python yourself, you can (more or less) use whichever version
> of Visual Studio you want. There is nothing that prevents you from building
> Python 2.7 or 3.4 with MSVC 14.
Python 2.7 provides project files (PCbuild/*) for Visual Studio 20
Hi,
Paul Moore wrote:
> The key point for me is that any supported build on Windows supports
> the exact same ABI.
It looks like ABI compatibility is a goal of Clang on Windows:
http://clang.llvm.org/docs/MSVCCompatibility.html
http://blog.llvm.org/2014/07/clangllvm-on-windows-update.html
Hi,
I opened an issue to track this vulnerability:
http://bugs.python.org/issue22638
SSL 3.0 is 8 years old, I guess that TLS is now widely deployed and
well supported?
I guess that Linux vendors will have to fix the issues directly in
OpenSSL directly. Should Python only be changed on Windows?
Hi,
At the end of August, I sent the PEP 475 which I wrote with
Charles-François Natali:
https://mail.python.org/pipermail/python-dev/2014-August/136077.html
https://mail.python.org/pipermail/python-dev/2014-September/136101.html
Antoine Pitrou wrote " I'm +1 on the whole PEP" and R. David
Oh, I forgot the link to the PEP:
http://legacy.python.org/dev/peps/pep-0475/
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ar
2014-10-28 22:36 GMT+01:00 Antoine Pitrou :
> Is there an implementation somewhere?
There is no implementation yet. This time, I chose to focus on the PEP
before working on an implementation :-)
We can work on the implementation if it helps discuss the PEP. I
created a repository 3 months ago, bu
> Also, distutils-sig does seem more appropriate,
IMO we need a new mailing to discuss which mailing list is the most
appropriate (which includes another new mailing list).
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
2014-11-27 13:28 GMT+01:00 Jesus Cea :
> http://bugs.python.org/issue20530#msg231584
Copy/paste of the message:
Preparing a presentation about Python Magic methods I found something
weird: (Python 3.4)
"""
>>> help(int.__lt__)
Help on wrapper_descriptor:
__lt__(self, value, /) <- THIS!!
Re
2014-11-27 13:41 GMT+01:00 Victor Stinner :
> 2014-11-27 13:28 GMT+01:00 Jesus Cea :
>> http://bugs.python.org/issue20530#msg231584
>
> Copy/paste of the message:
>
> Preparing a presentation about Python Magic methods I found something
> weird: (Python 3.4)
>
> "
2014-11-27 13:41 GMT+01:00 Victor Stinner :
> I am amused about the "/)" suffix in the signature. It happens to all
> magic methods.
If I remember correctly, it means that the function does not accept keywords:
>>> (3).__lt__(4)
True
>>> (3).__lt__(value=4
Hi,
I'm trying to follow the discussion about the PEP 479 (Change
StopIteration handling inside generators), but it's hard to read all
messages. I'm concerned by trollius and asyncio which heavily rely on
StopIteration.
Trollius currently supports running asyncio coroutines: a trollius
coroutine
2014-11-27 20:06 GMT+01:00 Guido van Rossum :
> The issue here is that asyncio only interprets StopIteration as returning
> from the generator (with a possible value),
I'm not sure that the issue is directly related to asyncio.
trollius_coro() raises a StopIteration to return the result to caller
2014-11-27 22:54 GMT+01:00 Victor Stinner :
> I don't see how it would work.
If it cannot be fixed, would it make sense to allow trollius to
continue to work as it currently works with something like "from
__past__ import generator_dont_stop"?
When I talked with a friend ab
2014-11-28 10:12 GMT+01:00 Greg Ewing :
> I don't understand. If I'm interpreting PEP 479 correctly, in
> 'x = yield from foo', a StopIteration raised by foo.__next__()
> doesn't get turned into a RuntimeError
The Trollius coroutine uses "raise Return(value)" which is basically a
"raise StopIterat
2014-11-28 3:49 GMT+01:00 Nick Coghlan :
> I think between contextlib and Trollius, the case is starting to be
> made for raising an UnhandledStopIteration subclass of RuntimeError,
> rather than a generic RuntimeError.
I modified Trollius to test such idea:
* Return inherits from Exception (not
2014-12-11 15:47 GMT+01:00 Giampaolo Rodola' :
> I still think the only *real* obstacle remains the lack of important
> packages such as twisted, gevent and pika which haven't been ported yet.
twisted core works on python 3, right now. Contribute to Twisted if
you want to port more code... Or star
Hi,
Yes, the link is dead. It looks like the following link contains the same info:
https://docs.python.org/devguide/triaging.html
Dead page:
https://web.archive.org/web/20090704040931/http://www.python.org/dev/workflow/
"Core Development > Issue Workflow"
Victor
2014-12-18 6:57 GMT+01:00 Raymo
http://bugs.python.org/issue22619
"Possible implementation of negative limit for traceback functions"
I see that Serhiy Storchaka reviewed a patch.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
More context:
2014-12-19 12:43 GMT+01:00 anatoly techtonik :
> https://github.com/nickstenning/honcho/pull/121
The link mentions the following changeset:
---
changeset: 93122:1a3143752db2
branch: 2.7
parent: 93112:927cca0b9337
user:R David Murray
date:Fri Oct 17 20:07
Hi,
To compile Python on Windows, there are a few information in the
Developer Guide:
https://docs.python.org/devguide/setup.html#windows-compiling
Python 3.5 now requires Visual Studio 2010 *SP1*, or newer Visual Studio:
http://bugs.python.org/issue22919#msg233637
I found PCbuild\readme.txt whi
2015-01-13 23:18 GMT+01:00 Steve Dower :
> Technically, Python 3.5 requires Visual Studio 2015
For me, it's *very* difficult to find how to install Visual Studio.
There are many different websites and web pages which mention Visual
Studio with a lot of versions and "flavors" (Express, Community,
U
2015-01-13 23:42 GMT+01:00 Brian Curtin :
> In the meantime, the first result searching for Visual Studio 2015
> came up with
> http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx,
> which seems to give you VS2015. I haven't tried to run it since I'm
> not on Windows a
2015-01-13 23:46 GMT+01:00 M.-A. Lemburg :
> Just a note of caution: for older preview releases of VS the
> only way to get back to a clean system was to reinstall
> Windows.
Does it mean that it's not possible to have VS 2008 and VS 2015
installed at the same time?
VS 2008 is required to build P
2015-01-13 23:15 GMT+01:00 Zachary Ware :
> The first line of the section you linked to is "The readme included in
> the solution has more details, especially on what additional software
> is required to build which parts of Python.", and 'readme' is a link
> to the readme on h.p.o. :)
Ok, I didn'
0 M.-A. Lemburg :
> On 13.01.2015 23:42, Brian Curtin wrote:
>> On Tue, Jan 13, 2015 at 4:36 PM, Victor Stinner
>> wrote:
>>> 2015-01-13 23:18 GMT+01:00 Steve Dower :
>>>> Technically, Python 3.5 requires Visual Studio 2015
>>>
>>> For me, it&#
2015-01-15 22:39 GMT+01:00 Ryan Gonzalez :
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
"Microsoft Windows SDK for Windows 7 and .NET Framework 4"
Are you sure that it is SDK 7.1, and not 7.0?
--
The SDK 7.0 works for Python 2.7 which is compiled with Visual Studio 2008.
I us
Oh by the way, the tool that I wrote to build wheel packages on Windows is here:
https://code.google.com/p/tulip/source/browse/release.py
It was too annoying to have to open 6 times the Windows SDK shell, and
type each time between 2 and 4 commands.
release.py help:
--
Usage: release.py [opti
Android provides a minimal support of locales. Most functions return a
fake result, do nothing. I'm not sure that it supports any codec. To
support Android, we may force UTF-8 for the filesystem encoding, as
done on Mac OS X.
Victor
2015-01-30 19:04 GMT+01:00 Ryan Gonzalez :
> No...
>
> ...but I
Oh, I found my old patch to force UTF-8 on Android. I didn't test it:
see attached file.
It would be nice to start a wiki page to collect all informations on
the Python port to Android.
Victor
2015-01-30 21:04 GMT+01:00 Victor Stinner :
> Android provides a minimal support of local
94463:0b3bc51341aa
>> parent: 94464:2cd6621a9fbc
>> user:Victor Stinner
>> date:Mon Feb 02 18:36:59 2015 +0100
>> summary:
>> Merge 3.4 (asyncio)
>
> IMO it would be nice to keep the original code in the
2015-02-02 21:49 GMT+01:00 Guido van Rossum :
> W00t! Congratulations les Français!
We will celebrate this acceptance with a glass of red wine and cheese.
Thanks Antoine! I hate EINTR. It's a pain to handle them for each
syscall in subprocess and asyncio (where signals are likely). It's
good to n
2015-02-02 22:11 GMT+01:00 Giampaolo Rodola' :
> I may be chiming in a little late, however, I'd have a question: does this
> affect non-blocking applications somehow?
> How often should we expect to receive EINTR?
Each time a program is interrupted by a signal while it was waiting
for a sycall. M
2015-02-03 15:25 GMT+01:00 Giampaolo Rodola' :
> OK, thanks for clarifying, this is a very nice addition. One last thing:
> should InterruptedError exception be deprecated? As far as I understand it
> should never occur again, right?
signal.setinterrupt() is not deprecated so you can still "disabl
Hi,
2015-02-06 0:27 GMT+01:00 Francis Giraldeau :
> I need to access frame members from within a signal handler for tracing
> purpose.
IMO you have a big technical or design issue here. Accessing Python
internals in a signal handler is not reliable. A signal can occur
anytime, between two instruc
Le 7 févr. 2015 22:34, "Greg Ewing" a écrit :
with --shared)
> You might be able to use Py_AddPendingCall to schedule
> what you want done outside the context of the signal
> handler.
I don't how it could work. You have to increment the reference counting,
but also maybe increment references to o
Le 8 févr. 2015 05:39, "Gregory P. Smith" a écrit :
> From there, in your signal handler you must try to acquire the newly
exposed keymutex and (...)
Stop! Acquiring a lock in a signal handler is just a crazy idea. It's very
far from an async signal-safe function.
> So until those are fixed (hoo
1 - 100 of 3215 matches
Mail list logo
