Marc-Andre Lemburg added the comment:
Steve: Could you please merge your changes into platform.py ?
I think it should go into Python 2.7.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Marc-Andre Lemburg <m...@egenix.com>:
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Marc-Andre Lemburg added the comment:
On 16.09.2015 13:22, Serhiy Storchaka wrote:
>
> A duplicate of issue19143?
I guess so.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Marc Bouvier:
The %e directive is missing in the Datetime documentation. I have tried this
directive in 2.6.6, 2.7.2, and 2.7.10 using
datetime.datetime.strftime(datetime.datetime.now(), '%A, %B %e, %Y') and it
works in all cases.
The below documentation line is pulled
Marc Bouvier added the comment:
Sorry, the documentation page I am looking at is
https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior
and
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior
Marc-Andre Lemburg added the comment:
On 05.09.2015 03:49, Alexander Belopolsky wrote:
>
> Alexander Belopolsky added the comment:
>
> Hmm, on Mac OSX "%" and "A%" are valid format strings:
>
>>>> time.strftime("%")
> '%'
Marc-Andre Lemburg added the comment:
On 02.09.2015 16:37, flying sheep wrote:
>
> hi mark, i’ve just lengthily replied to you on python-ideas.
>
> in short: nope! many command line tools that are relatively new (among them
> your examples git and pip) honor the specs, my ~/.c
Marc-Andre Lemburg added the comment:
On 03.09.2015 13:37, flying sheep wrote:
> all three OSs have stable, widely followed standards in place, and the idea
> of providing a python stdlib API for them received an almost unanimously
> positive response – with the sole exception being
Marc-Andre Lemburg added the comment:
The XDG standard seems to focus on desktop GUI applications and that's also
where it's mostly used. Python has it's own installation scheme, which is
documented at the top of sysconfig.py and which we've had ever since distutils
became part of the stdlib
Marc-Andre Lemburg added the comment:
FWIW: I still think that allowing to change .__class__ on instances of static
types if wrong and should be undone. If we want to make this a feature of the
language we should have a PEP and the associated discussion to be able to judge
and document
Marc-Andre Lemburg added the comment:
On 01.09.2015 04:38, Nathaniel Smith wrote:
> Mark Lemburg wrote:
>> Python code will generally assume that it can trust
>> builtin types. It doesn't expect 42 + 2 to clear out the root dir,
>> just because some package installed from
Marc-Andre Lemburg added the comment:
mktime() does change several global C runtime variables on Linux. See the man
page on http://linux.die.net/man/3/mktime
However, the Python documentation does not mention anything about having
time.tzname being tied to the C lib global:
https
Marc-Andre Lemburg added the comment:
BTW: The most portable way to access the timezone name of a given local time is
to use strftime() with %Z as format character.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
On 31.08.2015 10:44, Nathaniel Smith wrote:
> Before anyone panics about security issues, do keep in mind that the patch
> you're talking about
reverting fixed a buffer overflow which I strongly suspect could be used to
accomplish arbitrary
code exe
Marc-Andre Lemburg added the comment:
On 31.08.2015 11:55, Antoine Pitrou wrote:
>
> __class__ assignment can definitely be useful for monkey-patching, or other,
> purposes.
The feature certainly has its place for user defined types (see the
unpickle example), but I don't think
Marc-Andre Lemburg added the comment:
I agree with Mark. This feature opens up a security hole large enough to drive
a train through.
Looking at the python-dev thread, the only motivation appears to be making
module look more like classes. I'd suggest to propose a PEP for making changes
Marc-Andre Lemburg added the comment:
If I understand you correctly, the only advantage of using /MT is
not require admin privileges for installation of the VC2015 runtime
libs.
Since VC2015 will be used by a lot of applications in a few months,
and it's likely that MS will ship the runtime
Marc-Andre Lemburg added the comment:
On 17.08.2015 18:24, Steve Dower wrote:
We can't have Python run VCredist because it requires administrative
privileges and installing Python does not require those. This is actually one
of the biggest complaints about the current installer
Marc-Andre Lemburg added the comment:
What effect does this static linking of the VC runtime have on libraries that
extension modules link at dynamically ?
E.g. say I have an extension which links against an ODBC driver DLL using a
different VC runtime than the one used to build Python
Marc-Andre Lemburg added the comment:
Please use encoding='utf-8' as definition for codecs.encode() and
codecs.decode().
There is no adjustable default encoding in Python 3 anymore.
For Python 3.6 this should probably be fixed everywhere
Marc-Andre Lemburg added the comment:
On 21.07.2015 22:15, dlroo wrote:
dlroo added the comment:
If you are using mx.DateTime make certain you do not use the .strftime
method. If you use .strftime method and have a 60th second in your DateTime
object it will crash python with no error
Marc Schlaich added the comment:
I'm still +1 for an update in 2.7 as there are a lot of important bug fixes and
a new SQLite version is 100% backwards compatible for my medium to big size
(SQLAlchemy) SQLite applications.
--
___
Python tracker rep
Marc-Andre Lemburg added the comment:
On 30.06.2015 20:52, Min RK wrote:
Thanks for the feedback, I thought it might be a long shot. I will go back to
removing the *use* of the feature everywhere I can find it, since it is so
problematic and rarely, if ever, desirable.
Could you please
Marc-Andre Lemburg added the comment:
On 30.06.2015 22:49, Min RK wrote:
Could you please post an example of where the feature is problematic ?
setuptools/easy_install is the major one, which effectively does
`sys.path[:0] = pth_contents`, breaking import priority. This has been known
Marc-Andre Lemburg added the comment:
On 29.06.2015 21:30, Min RK wrote:
.pth files currently allow execution of arbitrary code, triggered by lines
starting with `import`. This is a rarely understood, and often misbehaving
feature. easy_install has used this feature to ensure that its
Marc Jofre added the comment:
Hi all,
I did more tests, identifying that the main issue I have resides in another
script (multiprocessing), when using nuitka compiler.
I will get back to you with more info when I solve the multiprocessing issue.
The command prompt dump is:
data: HTTP/1.0
Marc Jofre added the comment:
When executing, wsgiref produces the following error dump:
D:\SixSensoCytometerWebBased\include\binD:\SixSensoCytometerWebBased\include\bi
n\manage.exe runserver 8765
Validating models...
0 errors found
May 26, 2015 - 16:20:56
Django version 1.5.8, using settings
Marc-Andre Lemburg added the comment:
I was away the last few days, so just found the changes now.
IMO, it's a good idea to use a new module for the new compiler, but don't think
it's a good idea to make the whole module private, since this implicitly
disallows sub-classing the compiler class
Marc-Andre Lemburg added the comment:
Here's what mxDateTime uses:
import mx.DateTime
t1 = mx.DateTime.DateTime(2012,6,30,23,59,60)
t2 = mx.DateTime.DateTime(2012,7,1,0,0,0)
t1
mx.DateTime.DateTime object for '2012-06-30 23:59:60.00' at 7fbb36008d68
t2
mx.DateTime.DateTime object
Marc-Andre Lemburg added the comment:
On 18.05.2015 15:46, Stefan Krah wrote:
Stefan Krah added the comment:
The problem with this macro is that most of the time it takes the
standard cmp return value {-1,0,1} and converts that into a bool.
For this use case, it might be more
Marc-Andre Lemburg added the comment:
issue23042 is fixed now. libffi 3.2.1 apparently has the same issue, so the
issue23042 patch would probably have to be reapplied (slightly modified,
though).
Seeing that libffi has had a major compilation problem breaking it on at least
FreeBSD and most
Marc-Andre Lemburg added the comment:
On 14.05.2015 13:29, Petr Viktorin wrote:
Marc-Andre, Barry, you expressed interest in the macro on the mailing list;
do you still think it's a good idea?
Yes.
The fact that the macro can save us more than a hundred lines
of code in Python itself
Marc-Andre Lemburg added the comment:
See issue1322
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9514
Marc-Andre Lemburg added the comment:
See issue1322 for why we're closing this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17762
Changes by Marc-Andre Lemburg m...@egenix.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17762
Marc-Andre Lemburg added the comment:
On 13.05.2015 16:18, Petr Viktorin wrote:
Issues #17762 and #9514 had patches to improve these functions. Time to close
them?
Yes. I just did. Thanks for the reminder.
--
___
Python tracker rep
Marc-Andre Lemburg added the comment:
Looks good. Thanks, Serhiy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22682
___
___
Python-bugs-list
Marc-Andre Lemburg added the comment:
I like the idea of adding a free list of longs in Python 3, but I think we
should extend this somewhat to cover more ground, e.g. by pre-allocating a
block of 1 digit long objects, like we did for Python 2 ints, and perhaps
allocate up to 4k (= 1 memory
Marc-Andre Lemburg added the comment:
On 11.05.2015 11:42, Serhiy Storchaka wrote:
Pre-allocating a block has a disadvantage. It is hard to free allocated
block. The program can create a lot of integers, then drop most of them, and
request the memory for other needs, but blocks once
Marc-Andre Lemburg added the comment:
On 11.05.2015 21:03, Steve Dower wrote:
Steve Dower added the comment:
Simply because I didn't update the doc string :)
I don't really want to put a version number on this file, since it isn't MSVC
14.0 specific - it's MSVC 14 and all future
Marc-Andre Lemburg added the comment:
On 11.05.2015 23:50, Paul Moore wrote:
I agree with Steve, we shouldn't be constrained to preserve all the
undocumented internals of distutils - doing that in the past is what has made
distutils essentially unmaintainable.
I don't think there's
Marc-Andre Lemburg added the comment:
On 11.05.2015 23:20, Steve Dower wrote:
I guess we need a third opinion.
For me, the subclasses of CCompiler are undocumented and not a guaranteed
interface (people using them directly are consenting adults). They're also an
eyesore, so if I can
Marc-Andre Lemburg added the comment:
Why are you removing the mcvs9compiler.py file when at the same time your are
referencing it in the msvccompiler.py doc string ?
--- a/Lib/distutils/msvccompiler.py
+++ b/Lib/distutils/msvccompiler.py
@@ -1,201 +1,120 @@
distutils.msvccompiler
Contains
Marc-Andre Lemburg added the comment:
Thanks, Berker, your patch looks fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python
Marc-Andre Lemburg added the comment:
Here's a patch which I have tested on Linux, FreeBSD and Mac OS X.
It solves the problem with compiling in Windows calls on non-Windows platforms
and resynchronizes the ffi_raw_call() function with the ffi_call()
implementation. Both functions had
Marc-Andre Lemburg added the comment:
Changing the title to reflect that the solution to how to configure Python is
still up in the air.
I also started a thread on python-dev to get some more feedback.
--
title: Make default HTTPS certificate verification setting configurable via
Marc-Andre Lemburg added the comment:
Those are nice ideas, but you are forgetting two important points:
* browsers are typically only being used by single users,
applications by potentially hundreds or thousands of users
* how should the poor sys admin who's task it is to keep Python
Marc-Andre Lemburg added the comment:
On 05.05.2015 21:24, levkivskyi wrote:
Links to Python library documentation such as:
http://docs.python.org/library/functions.html
http://docs.python.org/library/itertools.html
http://docs.python.org/library/functools.html
etc.
are automatically
Marc-Andre Lemburg added the comment:
Adding Hye-Shik who wrote the codec.
--
nosy: +hyeshik.chang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Marc-Andre Lemburg added the comment:
I checked the registry to find the correct root. This would be
Software\Microsoft\VisualStudio\.
However, VC 9.0 no longer seems to set the variables the method is looking for,
so even if the .__root attribute problem gets fixed, the method would not find
New submission from Marc-Andre Lemburg:
Trying to use .get_msvc_path() on an distutils.msvccompiler.MSVCCompiler()
instance raises an AttributeError:
MSVCCompiler instance has no attribute '_MSVCCompiler__root'
The reason seems to be that self.__root is not set for Win x64 in .__init__
Marc-Andre Lemburg added the comment:
I think this discussion is moving in the wrong direction or least one which
won't help people not using some Linux distribution.
The use case here is very similar to the hash seed randomization which was also
successfully handled using an environment
Marc-Andre Lemburg added the comment:
On 23.04.2015 21:02, Behdad Esfahbod wrote:
They are used in OpenType fonts, but not implemented by Python at this time.
Here's are the Unicode mappings for them:
http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMANIAN.TXT
http://unicode.org
Marc-Andre Lemburg added the comment:
The x_ prefix was added as reminder and way to document the desire to look
into this at some point:
https://github.com/python/cpython/commit/c696b47b10db1fa22b77ecfe1af392b3d62aab61
Before adding more codecs, we always ask whether these are in actual use
Marc-Andre Lemburg added the comment:
On 24.04.2015 10:34, Behdad Esfahbod wrote:
Thanks Marc-Andre. If the x_ was indeed added for that reason, it's quite a
coincidence, because the MIME name of these encodings also starts with
x-mac-..., so I assumed that's where the x_ comes from.
Oh
Marc-Andre Lemburg added the comment:
On 24.04.2015 20:34, Behdad Esfahbod wrote:
They are a rather minor change on top of the existing Asian encodings. So
implementing them in Python might be easier. I have a half-done version of
those. I can try finishing and post it back here
Marc-Andre Lemburg added the comment:
Hi Ma Lin,
thank you for your investigation. In order to fix these tables, we'd need an
official reference which shows that there is in fact an error. If most
programming languages you have tested use the wrong version, then maybe it's
not wrong after
Marc-Andre Lemburg added the comment:
On 24.04.2015 04:54, aixtools wrote:
Rather than wait for that to happen I decided to experiment with LibreSSL. If
you are not familiar with LibreSSL - I shall be quick - openbsd (who also
maintains openssh) has been cutting out insecure
Marc-Andre Lemburg added the comment:
On 24.04.2015 21:25, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Guido's time machine strikes back.
'π–∆'.encode('mac_romanian')
b'\xb9\xd0\xc6'
'π–∆'.encode('mac_croatian')
b'\xf9\xe0\xb4'
Ah, I should have looked
New submission from Marc-Andre Lemburg:
In Python 2, the unicode() constructor does not accept bytes arguments, unless
an encoding argument is given:
unicode(u'abcäöü'.encode('utf-8'))
Traceback (most recent call last):
File stdin, line 1, in module
UnicodeDecodeError: 'ascii' codec can't
New submission from Marc-Andre Lemburg:
In Python 3.4.3, the doc string of the str() builtin still reads:
str(object='') - str\nstr(bytes_or_buffer[, encoding[, errors]]) -
str\n\nCreate a new string object from the given object. If encoding or\nerrors
is specified, then the object must
Marc-Andre Lemburg added the comment:
I agree with closing this as won't fix.
It is true that the encoding keyword argument is only useful when passing in
byte strings or (and that's also where it originated in Python 2: the default
string type is a byte string), but even in Python 3
Marc-Andre Lemburg added the comment:
On 22.04.2015 15:52, R. David Murray wrote:
str accepting bytes and returning the repr was a conscious design choice, as
evidenced by the -bb option, and I'm sure there is code that is both
unintentionally and *intentionally* using this, despite
Marc-Andre Lemburg added the comment:
On 17.04.2015 05:50, Larry Hastings wrote:
Larry Hastings added the comment:
The e variants (typically) allocate a buffer for you, since it's pretty
much unknown how long the encoded data will be.
All four will do it if you pass in a NULL pointer
Marc-Andre Lemburg added the comment:
On 17.04.2015 00:06, Steve Dower wrote:
So it looks like what I should do is use the include_dirs and library_dirs
members from CCompiler so they can be set through other properties.
I see that you're basically reading the include and lib
dirs from
Marc-Andre Lemburg added the comment:
On 17.04.2015 06:42, Larry Hastings wrote:
Larry Hastings added the comment:
One more idea. We annotate with an when you pass in a pointer to a
variable. So format unit 'i' would get [ int], 's' would get [ char *],
and 'es#' would get [char
Marc-Andre Lemburg added the comment:
On 17.04.2015 16:04, Steve Dower wrote:
Yeah, the basic functionality is no different, since there isn't really a
better way to handle future versions of VS automatically. I'd rather not
officially expose this stuff though.
Maybe you could override
Marc-Andre Lemburg added the comment:
We do some monkey-patching on MSVCCompiler as well, but mostly because
distutils doesn't define a good way to subclass or configure a compiler class.
IMO, monkey patching is a really bad idea. distutils should be evolved to
provide more proper extension
Marc-Andre Lemburg added the comment:
I'm not sure I like the way the simple idea Antoine has now resulted in a
complete mess across platforms.
None of this is documented anywhere except on this ticket.
Since the change is a major one for anyone creating installers, packagers or
otherwise
Marc-Andre Lemburg added the comment:
On 16.04.2015 18:12, Nick Coghlan wrote:
I can tell you exactly where these files need to live side by side: index
servers. We currently paper over it on PyPI for Windows and Mac OS X by
leveraging the implicitly defined ABI compatibility
Marc-Andre Lemburg added the comment:
On 16.04.2015 17:30, Matthias Klose wrote:
Matthias Klose added the comment:
Nick filed issue #23966 to document these changes. Yes, these tags should be
documented, so that installers don't have to guess (currently they are only
exposed
Marc-Andre Lemburg added the comment:
On 16.04.2015 18:53, Matthias Klose wrote:
I'm disappointed that you discredit any other use case besides what you think
as
the typical use case as not real life use case. Maybe you are focused on x86
only, but if you've been to PyCon 2014, you should
Marc-Andre Lemburg added the comment:
On 16.04.2015 15:18, Steve Dower wrote:
Is there a way for those users to specify the version that they want?
Indirectly, yes. There's the build_ext --compiler argument which then
interfaces to ccompiler.new_compiler. In essence, you can specify
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:44, Donald Stufft wrote:
Donald Stufft added the comment:
Perhaps you can point me to some use cases where the triple
platform tag is really useful.
If I understand correctly (and ABI isn't my strong suite), it would be useful
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:14, Marc-Andre Lemburg wrote:
However, for plain .so files that you have on your system (which will
mostly like not support more than 2-4 different architecture configurations
running at the same time), I don't currently see a need
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:47, Ned Deily wrote:
Ned Deily added the comment:
Antoine's ticket is the first in two decades to request being
able to install .so extension files side-by-side, so even if
times and platforms change, people don't seem to have a big
Marc-Andre Lemburg added the comment:
On 16.04.2015 20:17, Donald Stufft wrote:
Donald Stufft added the comment:
Well, it's even more wasteful if you have to download 100MB wheels
with all the different platforms when the dedicated wheel would just
need 1.5MB.
I think it's going
Marc-Andre Lemburg added the comment:
On 16.04.2015 20:21, Ned Deily wrote:
Ned Deily added the comment:
No, PEP 3149 is about the Python ABI, following PEP 3147,
which implements this for PYC files.
The intent is to be able to have mutliple *Python* ABI/API versions
installed side
Marc-Andre Lemburg added the comment:
On 17.04.2015 00:51, Donald Stufft wrote:
Since you need special support for such ZIP files (either using dlopen
hacks or temporarily extracting them), you might as well deal with
the platform dependencies in that handler. No need to force the
platform
Marc-Andre Lemburg added the comment:
On 17.04.2015 01:38, Larry Hastings wrote:
Documentation is here:
https://docs.python.org/3/c-api/arg.html#arg-parsing
The first line of documentation for each format unit follows this convention:
formatunit (pythontype) [arguments
Marc-Andre Lemburg added the comment:
Are you sure you want to go with OpenSSL 1.0.2a ? It typically takes a few
patch level releases for them to clear out all the major bugs (including
security relevant ones).
For egenix-pyopenssl, we've chose to stay with 1.0.1 for the time being until
Marc-Andre Lemburg added the comment:
On 14.04.2015 01:41, Donald Stufft wrote:
I'm pretty massively +1 in Python shipping 1.0.2 (or really, whatever the
latest OpenSSL is) wherever it can, including the OSX installers even on
systems where Apple ships it's ancient OpenSSL.
Eventually
Marc-Andre Lemburg added the comment:
On 14.04.2015 01:36, Ned Deily wrote:
https://github.com/openssl/openssl/pull/218
(certificate expiry checks not working)
That issue appears to have been fixed in 1.0.2a, no?
Yes, but it shows the kind of errors to expect in the early
stages of a new
Marc-Andre Lemburg added the comment:
On 14.04.2015 00:29, Ned Deily wrote:
For what it's worth, the resolution of Issue23476 uses an API that was added
in OpenSSL 1.0.2.
Hmm, I don't think that's a good move at this time.
Most Linux users won't benefit from this since their system
Marc-Andre Lemburg added the comment:
On 05.04.2015 23:25, R. David Murray wrote:
MAL: then what you are arguing for is that the SSL changes in 2.7.9 should
not have happened. Which is an argument that Antoine and I at least are
sympathetic to :)
I think those changes were probably
Marc-Andre Lemburg added the comment:
On 05.04.2015 18:28, Donald Stufft wrote:
Donald Stufft added the comment:
Now, I knew how to fix this, but the solution was not
an obvious one. I had to use truss to figure out where OpenSSL
was looking for certificates and the added the Mozilla
Marc-Andre Lemburg added the comment:
On 05.04.2015 21:36, Antoine Pitrou wrote:
And you want the python-dev community to care for that broken
situation by bearing the cost of additional maintenance and security
risk in implementing the new configuration options?
No, I want to be able
Marc-Andre Lemburg added the comment:
On 05.04.2015 21:48, Donald Stufft wrote:
Donald Stufft added the comment:
No, I want to be able to easily disable the newly added
checks in 2.7.9+ to get systems such as these behave the
same as with 2.7.8, since without this option, people
using
Marc-Andre Lemburg added the comment:
I wouldn't make this the default, since the probability is small, but not zero.
However, it may be worth exploring this as dict sub-type for applications to
use which could benefit from it.
For internal strings, we already use interning, so no win
Marc-Andre Lemburg added the comment:
@koobs: I was just looking at the 3.2.1 code where it still looks like
ffi_call_win32() gets called even on non-Win32 platforms.
That said, it's possible that ffi_call_win32() is indeed defined on other
platforms than Win32 as well in 3.2.1 - after all
Marc-Andre Lemburg added the comment:
I would prefer to have someone with good libffi knowledge to chime in here.
It's easy to just revert the patch, but it may be even better to upgrade the
included libffi lib.
But probably not to 3.2.1, since this still has the same bug it seems:
https
Marc-Andre Lemburg added the comment:
This is likely also related to issue23042.
The precompiler #ifdefs were mixed up, causing Win32 code to be compiled in on
other platforms as well.
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
Marc-Andre Lemburg added the comment:
On 08.03.2015 20:57, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
Well, that's not useful in a generated file.
Well, here's a case where it's useful... Asking me to change tools is quite
obvious and quite pointless at the same time. How
Marc-Andre Lemburg added the comment:
There seem to be quite a few other places where this simple optimization could
make sense as well, perhaps even going as far
as converting all uses of PyMem_MALLOC to PyObject_MALLOC.
There was a time when the small memory allocator did not return
free
Marc-Andre Lemburg added the comment:
Can you provide a patch for this ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23550
___
___
Python
Marc Schlaich added the comment:
Please fix this. Scripts with multiprocessing bundled as wheels are broken with
Python 2.7 on Windows: https://github.com/pypa/pip/issues/1891
--
nosy: +schlamar
___
Python tracker rep...@bugs.python.org
http
Marc-Andre Lemburg added the comment:
On 17.02.2015 19:34, Serhiy Storchaka wrote:
Proposed patch enhance locale testing. test__locale is converted to support
unittest discovery. When there are no suitable locales (e.g. there is only
POSIX locale) tests are reported as skipped. Tested
Marc-Andre Lemburg added the comment:
On 09.02.2015 16:17, Steve Dower wrote:
Steve Dower added the comment:
Including the one shipped in the stdlib? Python 3.5 no longer supports XP.
We normally have the platform.py module support multiple Python
versions (at least that's how we did
Marc-Andre Lemburg added the comment:
On 09.02.2015 15:14, Steve Dower wrote:
Steve Dower added the comment:
(Was reminded about this by #23417)
Any word on the back compat issues in platform.py? Can we make the version in
3.5 only work with Vista+, or do I need to handle XP in case
Marc added the comment:
Hi Ramchandra,
I actually have an AV (Sophos) but no firewall on the computer
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23337
501 - 600 of 2192 matches
Mail list logo
