Marc-Andre Lemburg added the comment:
On 08.10.2013 11:33, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> MS Notepad and MS Office save Unicode text files in UTF-16-LE,
>> unless you explicitly specify UTF-8, just like many other Windows
>> applic
Marc-Andre Lemburg added the comment:
On 08.10.2013 11:42, Serhiy Storchaka wrote:
>
> UTF-16 codec still fast enough. Let first make it correct and then will try
> optimize it. I have an idea how restore 3.3 performance (if it worth, the
> code already complicated enough).
T
Marc-Andre Lemburg added the comment:
On 08.10.2013 12:30, Antoine Pitrou wrote:
>
>> UTF-8, UTF-16 and UTF-32 codecs need to be as fast as possible
>> in Python to not create performance problems when converting
>> between platform Unicode data and the internal form
Marc-Andre Lemburg added the comment:
The patch looks good, except one nit:
if 'IronPython' in sys_version
is probably not supported in IronPython 2.0, since support for "n-char in
m-char" tests were added after Python 2.1.
Now, you can either leave this in and remov
Marc-Andre Lemburg added the comment:
On 17.10.2013 21:01, Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> I've looked at this, and the question is: Do we really need a capsule
> API? All relevant symbols in _decimal start with Py* and shouldn't
> ne
Marc-Andre Lemburg added the comment:
On 18.10.2013 11:39, Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> I believe you, but I'd like to understand why. :)
:-)
> It seems to me that a module and also PyInit_xxx() can be loaded portably.
> Say the handles t
Marc-Andre Lemburg added the comment:
On 19.10.2013 07:06, Martin Matusiak wrote:
>
> Martin Matusiak added the comment:
>
> It seems the versions of IronPython 1.0 mentioned in test cases do actually
> support the "in" keyword, so the first version of the patch
Marc-Andre Lemburg added the comment:
On 19.10.2013 12:11, Martin Matusiak wrote:
>
> Attaching a v3 which uses "in" and "startswith".
>
>
> Just for good measure I ran this module on IronPython 1.0 and it fails on
> import:
>
> - bytes literal:
Marc-Andre Lemburg added the comment:
On 19.10.2013 13:37, Martin Matusiak wrote:
>
> Martin Matusiak added the comment:
>
> Double checked that the test passes against both default and 2.7 branches.
>
> Is there anything else that needs to happen here or are you satisfied,
Marc-Andre Lemburg added the comment:
On 21.10.2013 02:07, Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Fixed, thanks for the patch!
Thanks, Ezio, for the check-in.
--
___
Python tracker
<http://bugs.pytho
Marc-Andre Lemburg added the comment:
On 24.10.2013 16:59, Andrei Dorian Duma wrote:
>
> I added a patch (my first patch!).
>
> platform.linux_distribution() now first looks in /etc/os-release. If this
> file is not found, checking continues as befo
Marc-Andre Lemburg added the comment:
Christian: I think adding MIME types falls under platform support and we do
still add platform support to Python 2.7.
That said, the mimetypes module *does* use platform files for determining MIME
types, so adding missing MIME types there will likely
Marc-Andre Lemburg added the comment:
On 04.11.2013 14:30, STINNER Victor wrote:
>
> It would be simpler to just drop these custom codecs (rot13, bz2, hex, etc.)
> instead of helping to use them :-)
-1 for the same reasons I keep repeating over and over and over again :-)
The cod
Marc-Andre Lemburg added the comment:
On 05.11.2013 21:31, STINNER Victor wrote:
>
> 2013/11/5 Alexander Belopolsky :
>> +1 on adding an option to isoformat(). We already have an optional
>> argument, so the symmetry with __str__ is not complete. To make this option
>
Marc-Andre Lemburg added the comment:
On 06.11.2013 16:51, Alexander Belopolsky wrote:
>
> MAL: Have you thought about the rounding/truncation issues
> associated with not showing microseconds ?
Sure, otherwise I wouldn't have mentioned it :-)
mxDateTime always uses 2 digit
Marc-Andre Lemburg added the comment:
On 10.11.2013 10:20, Nick Coghlan wrote:
>
> The long discussion in issue 7475 and some subsequent discussions I had with
> Armin Ronacher have made it clear to me that the key distinction between the
> codec systems in Python 2 and Pyt
Marc-Andre Lemburg added the comment:
On 10.11.2013 14:03, Nick Coghlan wrote:
>
> Updated patch (v5) with a more robust chaining mechanism provided as a
> private "_PyErr_TrySetFromCause" API. This version eliminates the previous
> whitelist in favour of checking direc
Marc-Andre Lemburg added the comment:
On 10.11.2013 15:39, Nick Coghlan wrote:
>
> On 10 November 2013 23:21, Marc-Andre Lemburg wrote:
>>
>> This doesn't look right:
>>
>> diff -r 1ee45eb6aab9 Include/pyerrors.h
>> --- a/Include/pyerrors.h
Marc-Andre Lemburg added the comment:
>> Then I don't understand changes such as:
>>
>> -'chinese-s':'zh_CN.eucCN',
>> +'chinese-s':'zh_CN.gb2312',
>>
Marc-Andre Lemburg added the comment:
Jan, the codec implements an encoding which has certain characteristics just
like any other codec. It works both in Python 2 and 3 without problems.
The documentation is no longer true, though. Ever since we added encoding
markers to source files, the raw
Marc-Andre Lemburg added the comment:
On 11.11.2013 20:21, Serhiy Storchaka wrote:
>
>> That's not intended. The normalize() function is supposed to
>> prepare the locale for the lookup. It's not supposed to be applied
>> to the looked up value.
>
> La
Marc-Andre Lemburg added the comment:
On 16.11.2013 10:16, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> The full input/output type specifications can't be implemented sensibly
> without also defining at least a ByteSequence ABC. While I think it's a goo
Marc-Andre Lemburg added the comment:
On 16.11.2013 13:44, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> Now that I understand Victor's proposal better, I actually agree with it, I
> just think the attribute names need to be "encodes_to" and &q
Marc-Andre Lemburg added the comment:
On 16.11.2013 14:25, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> Another big one: the encodings module API is not documented in the prose
> docs, and nor is the interface between the default search function and the
> i
Marc-Andre Lemburg added the comment:
On 16.11.2013 14:37, Nick Coghlan wrote:
>
> Such codecs can be represented (for 3.4) by simply not setting the attribute
> and leaving the output types unspecified. We don't need that complexity for
> the standard library, and the "
Marc-Andre Lemburg added the comment:
On 16.11.2013 15:03, Mark Lawrence wrote:
>
> Mark Lawrence added the comment:
>
> Could they be documented with a massive warning in red "Cpython
> implementation detail - subject to change without notice"? Or documented i
Marc-Andre Lemburg added the comment:
On 16.11.2013 15:52, Nick Coghlan wrote:
>
> The only reasonable way to accurately represent "anything that exposes a
> buffer memoryview can read" as a type check is to write an appropriately
> duck-typed ABC. You can't enume
Marc-Andre Lemburg added the comment:
On 19.11.2013 12:38, Nick Coghlan wrote:
>
> Given the time frame, how about we just go with Serhiy's suggestion of a
> "known non-Unicode codec" internal blacklist for both 3.3 and 3.4?
+1
--
__
Marc-Andre Lemburg added the comment:
On 21.11.2013 09:34, Serhiy Storchaka wrote:
>
> No, it is not official Microsoft codepage (it was introduced by IBM in its
> PC-DOS). AFAIK this encoding yet widely used in banking software. My old text
> files were written in this encoding
Marc-Andre Lemburg added the comment:
Nick: I've had a look at your second patch. A couple of notes:
* I think you should add the flag to the constructor of the CodecInfo
tuple subclass and then set this in the resp. codecs. The extra
constructor class method looks too much like a
Marc-Andre Lemburg added the comment:
On 22.11.2013 12:24, Marc-Andre Lemburg wrote:
>
> Nick: I've had a look at your second patch. A couple of notes:
>
> * I think you should add the flag to the constructor of the CodecInfo
>tuple subclass and then set this in t
Marc-Andre Lemburg added the comment:
On 22.11.2013 12:43, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> If _is_text_encoding may change in Python 3.5, you should add a comment to
> warn users to not use it and explain its purpose, maybe with a reference t
Marc-Andre Lemburg added the comment:
Victor, please accept the fact that the codec sub-system in Python
doesn't only have the Unicode implementation as target. It's
true that most codecs were added for the Unicode implementation,
but I deliberately designed the system to be open
Marc-Andre Lemburg added the comment:
On 22.11.2013 23:03, STINNER Victor wrote:
>
> I'm not sure that multibyte encodings other than UTF-8 are used in the world.
> I'm not convinced that we should support them. If the changes are small, it's
> maybe not a b
Marc-Andre Lemburg added the comment:
Anatoly, please read http://www.python.org/dev/peps/pep-0012/
The process you are describing is not correct. In particular, the discussion
happens before sending in a pull request.
As for discussion of the PEP process: that should happen on python-dev
Marc-Andre Lemburg added the comment:
I'm not sure whether changing the errno module to use enums would be
conceptually correct:
enums declare a fixed set of permitted values, but errno values can be any
integer, are platform dependent and are sometimes not unique (e.g. EWOULDBLOCK
= E
Marc-Andre Lemburg added the comment:
On 28.11.2013 15:45, anatoly techtonik wrote:
>
> anatoly techtonik added the comment:
>
>> The process you are describing is not correct. In particular, the discussion
>> happens before sending in a pull request.
>
> Post
New submission from Marc-Andre Lemburg:
Not sure whether this can be considered a bug, but Python 2.6.7 for example
showed the build revision in the sys.version:
>>> sys.version
'2.6.7 (r267:88850, Feb 9 2012, 18:56:05) \n[GCC 4.5.0 20100604
[gcc-4_5-branch revision 160292]]&#x
Marc-Andre Lemburg added the comment:
The "C" locale is part of the ANSI C standard. The "POSIX" locale is an alias
for the "C" locale and a POSIX standard, so we cannot just replace the ASCII
encoding with UTF-8 as we wish, so Antoine's patch won't w
Marc-Andre Lemburg added the comment:
On 09.12.2013 11:19, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Marc-Andre> AFAIK, Python 3 does work with ASCII data in the C locale, so I'm
> not sure whether this is a bug at all.
>
> What
Marc-Andre Lemburg added the comment:
On 20.06.2014 09:26, Nick Coghlan wrote:
>
> 2.7.8 will likely be earlier than expected in order to address the latest
> OpenSSL update for the Windows installers. So while the likely time frame for
> this hasn't changed (i.e. Novembe
Marc-Andre Lemburg added the comment:
On 20.06.2014 16:38, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> MAL - agreed on the version numbering implications of treating OpenSSL CVE's
> as CPython CVE's, but I think Guido pretty much answered that when h
Marc-Andre Lemburg added the comment:
The unicode-escape codec was used in Python 2 to convert Unicode literals in
source code to Unicode objects. Before PEP 263, Unicode literals in source code
were interpreted as Latin-1. See http://legacy.python.org/dev/peps/pep-0263/
for details.
The
Marc-Andre Lemburg added the comment:
On 24.06.2014 11:44, Serhiy Storchaka wrote:
>
> Note that 'raw-unicode-escape' is used in pickle protocol 0. Changing it can
> break compatibility.
Indeed. unicode-escape was also designed to be able to read back
raw-unicode-esca
Marc-Andre Lemburg added the comment:
The two functions serve a different purpose.
getdefautltlocale() specifically avoids calling setlocale() and is thread-safe
on Unix. It's purpose is to return the default locale string, not only the
encoding.
getpreferredencoding() only return
Marc-Andre Lemburg added the comment:
The patch would have to be updated to 3.5 (part of it no longer applies), but
other than that I think it's fine.
It may make sense to readd the comment for .getstate() to keep the state as
simple as possible ("The implementation should make sur
Marc-Andre Lemburg added the comment:
Why are you removing guarantees like these from the str docs:
"The original string is returned if *width* is less than or equal to
``len(s)``."
?
This doesn't seem to have anything to do with documenting bytes and bytearrays.
--
Marc-Andre Lemburg added the comment:
Pointing people to io.open() as alternative to codecs.open() is a good idea,
but that doesn't make codecs.open() less useful.
The reason why codecs.open() uses binary mode is to avoid issues with automatic
newline conversion getting in the way o
Marc-Andre Lemburg added the comment:
It looks like the IP address is being used by some viruses/trojans:
https://www.virustotal.com/en/ip-address/185.31.17.175/information/
It may help using e.g. b.global-ssl.fastly.net as CNAME for docs.python.org
(e.g. by adding it to the /etc/hosts
Marc-Andre Lemburg added the comment:
On 20.08.2014 09:28, Georg Brandl wrote:
>
> We know, but this will happen to any sites that have content hosted by a CDN
> such as Fastly.
I think we should have additional fallback domains setup
that go to frontend.python.org and then also get
Marc-Andre Lemburg added the comment:
On 20.08.2014 19:14, Donald Stufft wrote:
>
> For now I think Fastly has sufficiently handled the issue to not require some
> sort of backup system to need to be put in place. They are going to let me
> know how they are going to handle it l
Marc-Andre Lemburg added the comment:
On 31.08.2014 11:34, Wilberto Morales wrote:
>
> New submission from Wilberto Morales:
>
> I know that issues like this one are usually on the users(my) fault, but I
> think pip might be broken this time for real.
>
> Every time I r
Marc-Andre Lemburg added the comment:
On 06.09.2014 15:03, Nick Coghlan wrote:
> A "codecs._forget_codec" helper in the C module would be all that was needed
> to handle it. Other implementations could then also use that to clear their
> own internal cache (if they have on
Marc-Andre Lemburg added the comment:
On 06.09.2014 21:14, Nick Coghlan wrote:
>
> This investigation also showed why the original tests that used a
> non-unique name didn't work: the codec was getting cached the first time
> through and hence not seeing the different codecs re
Marc-Andre Lemburg added the comment:
On 11.09.2014 01:04, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> Just as a recap of at least some of the *current* ways to do a bytes -> hex
> conversion:
>
>>>> import codecs
>>>> codecs.
Marc-Andre Lemburg added the comment:
On 15.09.2014 15:19, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> IMO test_codecs_fix1.patch is still needed.
>
> Review of Nick's change:
>
> +interp = PyThreadState_GET()->interp;
> +if
Marc-Andre Lemburg added the comment:
Don't like the function name :-)
How about codecs.filter_non_utf8_data(), since that's closer
to what the function is really doing and doesn't require
knowledge about what "surrogateescape" is.
Marc-Andre Lemburg added the comment:
On 23.09.2014 13:12, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> Draft docstring for that version
>
> def convert_surrogates(data, errors='replace'):
> """Convert escaped su
Marc-Andre Lemburg added the comment:
I think it's better to keep pybench speed performance oriented and rather use a
new tool for memory performance tests.
I've recently done a lightning talk at PyCon UK on the subject and found the
current tools we have for memory tes
Marc-Andre Lemburg added the comment:
Thanks, Serhiy.
The patch looks good, except for one nit: the makelocalealias.py normaly also
generates a list of changes and these are put at the top of the locale_alias
dictionary.
Could you add that as well
Marc-Andre Lemburg added the comment:
Thanks, Serhiy
The patch looks good. Please apply.
--
___
Python tracker
<http://bugs.python.org/issue20076>
___
___
Pytho
Marc-Andre Lemburg added the comment:
On 01.10.2014 09:52, Serhiy Storchaka wrote:
>
> The makelocalealias.py generates only a list of removes and updates, not
> additions.
Ah, ok.
> I recommend first apply issue20076, it will eliminate most additions.
Agreed. Please apply
Marc-Andre Lemburg added the comment:
On 02.10.2014 10:24, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> A lot of buildbot failed. Example:
>
> http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2692/ste
Marc-Andre Lemburg added the comment:
On 02.10.2014 10:38, Marc-Andre Lemburg wrote:
>
> What I don't understand is why the above case failed. That mapping
> wasn't changed by the patch, AFAICT.
Ah, the change is in the second patch round you applied, which
is not on the
Marc-Andre Lemburg added the comment:
On 02.10.2014 11:13, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> Test failed due to mismatch between glibc and X11 locale.alias (issue20087).
>> In X11 locale.alias ca_ES is mapped to ca_ES.ISO8859-1, and i
Marc-Andre Lemburg added the comment:
I don't think we should add more EBCDIC codecs to Python's stdlib. It would be
better to put a Python package on PyPI which people using these encodings can
use.
--
___
Python tracker
<http://bu
Marc-Andre Lemburg added the comment:
On 16.12.2013 10:02, STINNER Victor wrote:
>
> Maybe we should modify Py_FatalError() to call exit(1) in release mode, and
> only call abort() in debug mode? Dumping a core dump, opening a Windows fatal
> error popup, calling Fedora ABRT hand
Marc-Andre Lemburg added the comment:
On 16.12.2013 10:30, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> 2013/12/16 Marc-Andre Lemburg :
>> I don't think changing Py_FatalError() is a good idea. However,
>> its use in this particular case (stre
Marc-Andre Lemburg added the comment:
On 18.12.2013 22:57, Serhiy Storchaka wrote:
>
> Marc-Andre, do you have comments or objections?
Your last patch looks fine, but I don't have time to test it.
Regarding the broken *devanagari* entries in the alias table:
I think we shoul
Marc-Andre Lemburg added the comment:
I have tried this with a stock Python 2.7.6 version and don't get an error:
>>> platform._sys_version('2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1
>>> Compatible Apple LLVM 5.0 (clang-500.0.68)]')
('CPython
Marc-Andre Lemburg added the comment:
On 19.12.2013 00:39, Wes wrote:
>
> Marc
>
> Thanks for getting back to me so quickly on this. I'm running an apple
> version of python from the looks of it. I was running an Anaconda version
> at the time I posted this script, bu
Marc-Andre Lemburg added the comment:
On 19.12.2013 00:52, Wes wrote:
>
> Marc,
>
> Here was the initial output:
>
>>>> platform.__file__
> '/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
>>>> import sys
>>>> sys.version
Marc-Andre Lemburg added the comment:
Closing, since there's nothing much we can do about the problem.
--
resolution: -> invalid
status: open -> closed
versions: +3rd party -Python 2.7
___
Python tracker
<http://bugs.python.
Marc-Andre Lemburg added the comment:
On 20.12.2013 12:36, Serhiy Storchaka wrote:
>
> Proposed patch updates locale alias table to most recent locale.alias file
> (from X.org 7.7 distribution).
Looks good.
BTW, regarding the devanagari cases:
There is some recent activity in glib
Marc-Andre Lemburg added the comment:
On 20.12.2013 12:19, Serhiy Storchaka wrote:
>
> Added file: http://bugs.python.org/file33231/locale_devanagari_2.patch
See my message on issue20034:
There is some recent activity in glibc related to these. Here's a
patch that adds the sd_IN
Marc-Andre Lemburg added the comment:
On 20.12.2013 15:55, Serhiy Storchaka wrote:
>
> After applying the patch Python supports all ks_IN and sd_IN locales.
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string for
Marc-Andre Lemburg added the comment:
On 20.12.2013 16:12, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> Looks good.
>
> Should these patch be applied only to 3.4 or to all maintained
> releases? I suppose the later, because alias table which
Marc-Andre Lemburg added the comment:
On 20.12.2013 16:24, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> Well, yes, but only because you are removing the @-modifiers. I don't
>> think that's correct, since e.g. the string formatting used f
Marc-Andre Lemburg added the comment:
On 21.12.2013 20:33, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Example.
>
> 'br_fr':'br_FR.ISO8859-1',
> -'br_fr.iso88591':
Marc-Andre Lemburg added the comment:
On 21.12.2013 16:31, Christian Heimes wrote:
>
> All VMS code has been removed except for some code in Lib/platform.py.
>
> MAL:
> Do you want to keep the code in the platform module?
The platform.py module is intended to be usable by
Changes by Marc-Andre Lemburg :
--
assignee: lemburg -> christian.heimes
___
Python tracker
<http://bugs.python.org/issue16136>
___
___
Python-bugs-list mai
Marc-Andre Lemburg added the comment:
I thought some more about this approach. I'm +1 on it. The locale
lookup is not time critical, so the table optimization makes sense.
Nice idea, Serhiy !
On 22.12.2013 00:38, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
Marc-Andre Lemburg added the comment:
On 26.12.2013 19:59, Serhiy Storchaka wrote:
>
> Could you please make a decision about last patch, Marc-Andre?
Looks good. Thanks, Serhiy.
--
___
Python tracker
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
On 26.12.2013 21:19, Serhiy Storchaka wrote:
>
> Here is updated patch. It doesn't include any additions to locale alias table
> (including devanagari). Added several tests cases (many other test cases for
> removed aliases already exis
Marc-Andre Lemburg added the comment:
On 26.12.2013 22:43, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> Could you add a test for the optimization function ?
>
> I have no ideas. The optimization function is a part of the
> makelocalealias.py
&
Marc-Andre Lemburg added the comment:
On 26.12.2013 23:19, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> I probably wasn't clear: I meant some tests that show that the
>> alias definitions (on the left) from the X11 file are actually mapp
Marc-Andre Lemburg added the comment:
None of the linked patch URLs work anymore.
Could someone please upload a current patch to the ticket for review ?
As mentioned before, I don't believe that changing the function to first try
the lsb-release will result in the same results as wha
Marc-Andre Lemburg added the comment:
Another example on openSUSE 12.3:
# lsb-release -a
LSB Version:n/a
Distributor ID: openSUSE project
Description:openSUSE 12.3 (x86_64)
Release:12.3
Codename: Dartmouth
This would result in ('openSUSE project', '11.4
Marc-Andre Lemburg added the comment:
On 06.01.2014 11:53, Vajrasky Kok wrote:
>
> Here is the patch to deprecate platform.dist and platform.linux_distribution.
>
> --
> nosy: +vajrasky
> Added file: http://bugs.python.org/file33324/deprecate_platform_dist.patch
Tha
Marc-Andre Lemburg added the comment:
I'd be +1 on such a patch if we were to officially support Android, but we'd
need a volunteer to champion for this (which would be a good thing, IMO).
Otherwise, such changes need to be maintained
Marc-Andre Lemburg added the comment:
On 27.01.2014 11:00, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I agree with Antoine, I dislike the idea of BinaryTransformWrapper, it
> remembers me the evil codecs.EncodedFile thing.
>
> What are the usecase
Marc-Andre Lemburg added the comment:
On 03.02.2014 02:24, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Ever used "recode" ?
>
> No, what is it? I once used iconv for short tests, but I never required iconv
> to convert a real docu
Marc-Andre Lemburg added the comment:
On 25.02.2014 15:29, Felipe Sateler wrote:
>
> I'm sorry but I definitely don't have time or knowledge about python
> to propose a patch (simply removing pyconfig.h clearly doesn't work).
>
> As to the question, please c
Marc-Andre Lemburg added the comment:
On 06.03.2014 10:30, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> I agree that having midnight evaluate to false is completely unexpected and
> unintuitive. I can imagine situations where it bites people in productio
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
> Ezio Melotti added the comment:
>
> The Vista machine is running Py 2.5.2 but is not mine so I can't
> test/debug the issue properly there. FWIW I tried win32_ver() on it and
> I got ('', '6.0
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
> Ezio Melotti added the comment:
>
> Here are the results.
> Windows Vista SP2 in English
> Python 3.0.1:
> >>> platform.platform()
> 'Windows-Vista-6.0.6002-SP2'
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
> Ezio Melotti added the comment:
>
> On the Vista machine that returned ('', '6.0.6002', 'SP2',
> 'Multiprocessor Free') there is ActiveState's Python 2.5.2 that includes
>
Marc-Andre Lemburg added the comment:
I don't understand the use case for this.
If the StreamWriter/Reader cannot pickle the underlying stream (which is
probably always the case), why should the object itself be pickleable ?
What we could do is implement .__get/setstate__() and have it
Marc-Andre Lemburg added the comment:
Or use the "original" lib on which this is all based :-)
http://www.egenix.com/products/python/mxBase/mxDateTime/
(and which, of course, does allow subtracting times)
--
nosy: +lemburg
___
Pyth
Marc-Andre Lemburg added the comment:
Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be
removed or renamed to .compiler_obj. There's a lot of bdist_ext
distutils code out there relying on having the .compiler object available.
A much better fix would be to map the o
1201 - 1300 of 1946 matches
Mail list logo
