Marc-Andre Lemburg added the comment:
Maxim Koltsov wrote:
>
> New submission from Maxim Koltsov :
>
> Python docs (http://docs.python.org/library/time.html#time.time) say that
> time.time() function should return UTC timestamp, but actually i get local
> one:
>>&g
Changes by Marc-Andre Lemburg :
--
assignee: -> docs@python
components: +Documentation, Library (Lib)
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issu
Changes by Marc-Andre Lemburg :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue12758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> A PEP 393 draft implementation is available at
> https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into
> 3.3, this issue will be outdated: there won't be "narrow" builds of Python
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> #10542 proposes the following macros to factor out common code:
> #define _Py_UNICODE_ISSURROGATE
> #define _Py_UNICODE_ISHIGHSURROGATE
> #define _Py_UNICODE_ISLO
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
> So keeping your preamble bits, I might have considered doing it
> this way if it were me doing it:
>
> #define _Py_UNICODE_IS_SURROGATE
> #define _Py_UNICODE_IS_LEAD_SURROGATE
> #define _Py_UNICODE_
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I'm reposting my patch from #12751. I think that it's simpler than
> belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't
&
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> STINNER Victor wrote:
>>
>> STINNER Victor added the comment:
>>
>> I'm reposting my patch from #12751. I think that it's simpler than
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le 17/08/2011 07:04, Ezio Melotti a écrit :
>> As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and
>> Py_UNICODE_JOIN_SURROGATES can be committ
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> Ezio used two different naming schemes in his email. Please always
>> use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).
>
> Indeed, that was a typ
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> For bug fixes, you can put the macros straight into unicodeobject.c,
>> but please leave unicodeobject.h untouched - otherwise people will
>> mess around with the
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I don't think that macros specific to unicodeobject.c should get the
> _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but
> symbols re
Marc-Andre Lemburg added the comment:
Some thoughts:
* We can't change the value of a system variable in a patch level
release. It's not a bug and the change is not motivated by
Python, but by the OS vendor. So changes to released versions
are not possible. They ar
Marc-Andre Lemburg added the comment:
James Y Knight wrote:
>
> James Y Knight added the comment:
>
> M.A., your comments do not make sense in the context of Linux. It does not
> actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive
> than Linux 2.6.
Marc-Andre Lemburg added the comment:
Barry A. Warsaw wrote:
>
> Barry A. Warsaw added the comment:
>
> On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:
>
>> As for the cases where "linux3" is reported: I don't care that
>> they break. Python
Marc-Andre Lemburg added the comment:
James Y Knight wrote:
>
> James Y Knight added the comment:
>
>> Sure, you can compile and run Python on both versions of Linux, but
>> what if your application uses features that are only present in Linux
>> 3.0 and later ?
Marc-Andre Lemburg added the comment:
Martin von Gagern wrote:
>
> Martin von Gagern added the comment:
>
> Marc-Andre Lemburg wrote:
>> Both Python and the application will make certain assumptions about
>> the platform depending on the compile time environment.
&g
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> The suggested change removes the compile time information from
>> the platform string, so that information needs to be preserved
>> in a new attribute.
Marc-Andre Lemburg added the comment:
Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
>> We do have distutils to read the full compile time information
> We have sysconfig in the stdlib in 2.7 and 3.2+.
Right (it originated in distutils), but it has the same pr
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> Please reread the quoted sentence:
>>
>> The *compile time* version information needs to be preserved.
>
> Then please give it a very explicit name,
Marc-Andre Lemburg added the comment:
James Y Knight wrote:
>
> YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't
> it, since that's been fixed at linux2 approximately forever). Why do you
> think people would suddenly start needing to know
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> It's really hard to follow this issue. I'm trying to sum up, please comment
> my message if I'm wrong.
>
> --
>
> If I understood correctly,
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> MAL wrote:
>
>> As already mentioned, the diff between Linux 2.x and 3.x will
>> grow over time and while there may not be much to see now,
>> thing
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>>> The only way I can read this argument that makes any sense to me is
>>> that you are arguing for a precise build-time OS string. If it is
>>> su
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> #12326 proposes to remove the major version from sys.platform. If we remove
> it, we will need another easy way to get this information. I don't think that
> we n
Marc-Andre Lemburg added the comment:
Georg Brandl wrote:
>
> Also, we might think about removing this version number everywhere.
+1
--
___
Python tracker
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> So what about doing the same for FreeBSD, SunOS, and Windows?
>
> I agree that's definitely out of scope of this issue.
We could change the title of the ticket
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I'm not sure I understand why platform.release() isn't sufficient
>> for this purpose. Note that some systems return alphanumeric
>> values for platfor
Marc-Andre Lemburg added the comment:
Moved the discussion here from issue12326:
>> [Larry Hastings]
>> >> If we're changing "linux2" / "linux3" to just "linux", we should be
>> >> consistent and do it for everybody. I propo
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> We could change the title of the ticket :-)
>
> No please, move the discussion to #12795 which has a well defined title. This
> issue is closed. (#12795 has also
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
>> What we could do is add a function that tries to find out the
>> true version number of the OS, e.g. for Windows 7 that would
>> be (6, 1, 7601) instead of the marketing name '7' returned by
>
Marc-Andre Lemburg added the comment:
Nick Coghlan wrote:
>
> As a separate, but related point, IncrementalDecoder.getstate() includes an
> explanation on how to save arbitrary state as an integer, but no such
> explanation (not even a reference to the IncrementalDecoder
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> FreeBSD or OpenBSD release major version frequently, something like one
> per year, or one per two years. FreeBSD and OpenBSD developers knows
> that for years, and P
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Well, it is important to somehow get the build information for
>> Python, since that tells us which OS features were available
>> at the time of compilation.
Marc-Andre Lemburg added the comment:
[This discussion is really off-topic for this issue, it should either
be moved to issue12795 or a new ticket]
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>>> No, it doesn't (except for a bug that Matthias Klos
Marc-Andre Lemburg added the comment:
Tennessee Leeuwenburg wrote:
>
> Tennessee Leeuwenburg added the comment:
>
> Some more tests, updated initial state of BufferedIncrementalEncoder to be
> the correct type, updated rst file. Bit tired, hope I got it right!
>
> Th
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> sys.platform refers to build time information,
>> so the platform module won't help.
>
> When I wrote my patch, I realized that sys.platform is used t
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> The attached patch adds the following 4 public macros to unicodeobjects.h:
> Py_UNICODE_IS_SURROGATE(ch)
> Py_UNICODE_IS_HIGH_SURROGATE(ch)
> Py_UNICOD
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>>> It is mostly to test FreeBSD major version, and it looks like Python is
>>> build on the same FreeBSD major version that it is running on. Maybe
>>> b
Marc-Andre Lemburg added the comment:
Tennessee Leeuwenburg wrote:
>
> Tennessee Leeuwenburg added the comment:
>
> Thanks for the review. Here is a patch incorporating the two comments being
> to move some comments.
Hmm, the documentation patch doesn't appear to h
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC
> is supported at build time.
I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether the d
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> New submission from Ezio Melotti :
>
>>From Chapter 03 of the Unicode Standard 6[0], D91:
> """
> • UTF-16 encoding form: The Unicode encoding form that assigns each Unicode
> scalar value
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> I said "warn about the use of non-builtin modules", not disallow
>> their use. AFAIK, the purpose of the exercise is to reduce the
>> number of non-
Marc-Andre Lemburg added the comment:
Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
> Is it guaranteed that the -b option will be present in every version of file?
Looking at the only use case of _syscmd_file(), it may not even be worth
the trouble of adding the -b op
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Looking at the only use case of _syscmd_file(), it may not even
>> be worth the trouble of adding the -b option. Fixing the doc-string
>> may be enough: (..
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> @r.david.murray, @lemburg: So, can I commit my patch?
Yes, go ahead with 3.2 patch. It should not go into 2.7, though,
since it doesn't solve any problems in 2.7.
If
Marc-Andre Lemburg added the comment:
Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> As we move more and more infrastructure into Python code, we're going to see
> this pattern (i.e. a bootstrap module underlying the real module) more and
> more often
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> mmap, buffer, bytearray, string and unicode objects set the char buffer
> callback (bf_getcharbuffer). The bytearray object sets also the release
> buffer callback
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Note that the buffer interface release API is meant to protect
>> against such modifications, so I don't see why rejecting objects
>> that do implement this
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Here you have a patch. It adds tests in test_sys.
>
> The tests are skipped on a non-ascii Python executable path because of #8611
> (see #9425).
Thanks for the patc
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> Attached is a patch implementing the change agreed upon in the earlier
> discussion. This will allow wchar_t <-> Py_UNICODE conversions to use memcpy
> on s
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> Thanks. I dug into that a little just now, and it turns out to happen
> automatically.
>
> If ./configure doesn't define HAVE_WCHAR_H then it also will no
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> The command line -h explanation is missing from the patch.
>
> done
>
>> The documentation should mention that the env var is only
>> read once; subse
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Oh, I realized that PYTHONFSENCODING is ignored on Windows and Mac OS X.
> r84201 and r84202 fix test_sys, and r84203 fixes the documentation and Python
> usage (hid
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>>> Oh, I realized that PYTHONFSENCODING is ignored on Windows and Mac OS X.
>>> r84201 and r84202 fix test_sys, and r84203 fixes the documentation and
>>>
Marc-Andre Lemburg added the comment:
While you're right that adjusting the FS encoding long after Python has already
started is probably not such a good idea, I do think that we need to provide a
way to set the FS encoding from within Python without having to rely on
external set
Marc-Andre Lemburg added the comment:
Mark Lawrence wrote:
>
> Mark Lawrence added the comment:
>
> @Marc-Andre as there's no comments since your last post would you like to
> take this forward, cheers.
I'm fine with adding the alias, but currently don't have
Marc-Andre Lemburg added the comment:
Stefan Behnel wrote:
>
> Stefan Behnel added the comment:
>
> Another updated patch with a readability fix (replacing the last one).
While you're at it, you might as well remove references to the
"char buffer" - there's
Marc-Andre Lemburg added the comment:
Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> r84229
Thanks, Benjamin !
--
___
Python tracker
<http://bugs.python.
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> The underlying problem here is that SIZEOF_WCHAR_T is not defined in
> pyconfig.h on Windows. My patch assumed that it would be defined on all
> platforms whe
Marc-Andre Lemburg added the comment:
Closing the report: eu_es has been Python for quite a while (at least since
Python 2.5).
If you also feel that 'basque' should be added as alias, please provide proof
that this alias is really in use and open a new bug report.
-
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Think of e.g. embedded Python interpreters or py2exe-style applications
>> running on Linux or other systems that don't use Unicode APIs
>> for FS-intera
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> Which specific clause of the license do you consider violated?
* 3. All advertising materials mentioning features or use of this
*software must display the following ac
Marc-Andre Lemburg added the comment:
I'd suggest to add a paragraph like this to the release pages:
"""
The Python Windows installers include OpenSSL, which provides cryptographic
services to Python. Please note that downloading or using cryptographic
code may not be lega
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>>> Which specific clause of the license do you consider violated?
>>
>> * 3. All advertising materials mentioning features or use of this
>> *
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Since we are not following those old-style BSD license requirements
>
> You state that is if it was a fact, which is it not. We, indeed, fully
> comply with
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>>>> Think of e.g. embedded Python interpreters or py2exe-style applications
>>>> running on Linux or other systems that don't use Unicode APIs
&g
Marc-Andre Lemburg added the comment:
Terry J. Reedy wrote:
>
> Terry J. Reedy added the comment:
>
> This is really two issues: docs and windows builds. As for docs:
>
> Many of the module doc pages mention original authors and give urls for
> further info. The
Marc-Andre Lemburg added the comment:
Raymond Hettinger wrote:
>
> Raymond Hettinger added the comment:
>
> FYI, there is a section of the docs devoted to notifications and attribution
> licenses:
>
> http://docs.python.org/license.html#licenses-and-acknowledgem
Marc-Andre Lemburg added the comment:
Krauzi wrote:
>
> New submission from Krauzi :
>
> Hi guys,
> i recently found out that PyObject_Print is not working with Visual Studio
> 2010:
>
>
> #include
> #include
>
> int main( int argc, c
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> "keep the C function"
>
> Hum, currently, Python3 only has a *private* function called
> _Py_SetFileSystemEncoding() which can only be called after _Py_Initi
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> It would be nice to support PEP 383 (surrogateescape) on Windows, but the
> mbcs codec doesn't support it for performance reason. The Windows functions
> to encode
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I didn't proposed to add a new parameter to Py_InitializeEx() (which means
> create a new function to not break the API), I just wrote that
> _Py_SetFileSystemEnco
Marc-Andre Lemburg added the comment:
We can reconsider this at some later time, when Python 2.x is not really used
much anymore.
--
resolution: -> postponed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
Just another data point for the discussion:
The PSF is currently funding the effort to port pyOpenSSL to
Python 3.x and the port is nearly finished.
It may be worthwhile investigating adding the EVP interface
from evpy (with the ctypes bindings converted
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> It may be worthwhile investigating adding the EVP interface
>> from evpy (with the ctypes bindings converted to real C wrappers)
>> to pyOpenSSL and then adding t
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> pyOpenSSL is stable, in production use and
>> has a decent API. The ssl module is good enough for HTTPS client
>> use. pyOpenSSL provides a robust server side imp
Marc-Andre Lemburg added the comment:
Added OpenSSL license to Python 2.7, 3.1 and 3.2 in r84938, r84939, r84940 resp.
Now we'll only need to add a mention of the fact that we ship OpenSSL in the
Windows installers on the download page.
Terry, would you like to move this forward wit
Marc-Andre Lemburg added the comment:
geremy condra wrote:
>
> geremy condra added the comment:
>
> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
> wrote:
>>
>> Marc-Andre Lemburg added the comment:
>>
>> Antoine Pitrou wrote:
&g
Marc-Andre Lemburg added the comment:
geremy condra wrote:
>
>>>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>>>> the pyOpenSSL code to the Python stdlib based on a contributor
>>>> agreement. This would enable us to relicense
Marc-Andre Lemburg added the comment:
geremy condra wrote:
>
>>> The intention all along has been that we use the C API, and in fact
>>> I'm pretty far along on writing that. Assuming there won't be an issue
>>> with porting pyopenssl to python3, this
Marc-Andre Lemburg added the comment:
geremy condra wrote:
>
> geremy condra added the comment:
>
>>>> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
>>>> is planning for an alpha release next month.
>>>
>>> Do you kn
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> New version of the patch:
> - reencode sys.path_importer_cache (and remove the last FIXME)
> - fix different reference leaks
> - catch PyIter_Next() failures
> -
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Why is this needed ?
>
> Short answer: to support filesystem encoding different than utf-8. See #8611
> for a longer explanation.
>
> Example:
>
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> PyUnicode_AsWideChar() doesn't merge surrogate pairs on a system with 32 bits
> wchar_t and Python compiled in narrow mode (sizeof(wchar_t) == 4 and
> sizeof(P
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Forget my previous message, I forgot important points.
>
>> So the only reason why you have to go through
>> all those hoops is to
>>
>> * all
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le mercredi 29 septembre 2010 13:45:15, vous avez écrit :
>> Marc-Andre Lemburg added the comment:
>>
>> STINNER Victor wrote:
>>> STINNER Victo
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> On UNIX/BSD systems, Python decodes arguments with the locale encoding,
> whereas subprocess encodes arguments with the fileystem encoding. If both
> encodings are dif
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> The problem with command line arguments is that they don't necessarily
>> have just one encoding (just like env vars may well use more than
>> one encod
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I don't know how to test "if Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2". On
> Windows, sizeof(wchar_t) is 2, but it looks like Python is not prepare
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
>> You can tweak the Windows pyconfig.h to use UCS4, AFAIK, if you want to
>> test drive this case.
>
> I seem to recall seeing some other code that a
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> I like this solution because it doesn't change a lot of things. I agree to
> drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more
> inconsistencies than it solved.
If you remove the
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> If you remove both, Python will get very poor grades for OS
>> interoperability on platforms that often deal with multiple
>> different encodings for file na
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Being pedantic about forcing some encoding onto things that don't
>> have an encoding won't really work out in practice. Dealing with
>> file names,
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> New submission from Martin v. Löwis :
>
> Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on
> Windows, see http://www.pasteall.org/16215
>
> I think it is inco
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
> 2. COMPUTERNAME returns an uppercase version of the host name (which we
>could lowercase to stay b/w compatible), however I'm not sure
>whether this is the same as the socket.gethostname() or the
>NET
Marc-Andre Lemburg added the comment:
I've been in touch with the copyright holders of pyOpenSSL and they all were
positive about contributing the code to the PSF under a contributor agreement.
The idea would then be to add the crypto routines to pyOpenSSL and have that
added to the s
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> I've been in touch with the copyright holders of pyOpenSSL and they
>> all were positive about contributing the code to the PSF under a
>> contributor a
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>>> This sounds a bit ridiculous. Why not add the crypto routines directly
>>> to the stdlib?
>>
>> To make those routines available to a broader au
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> More evidence that the NetBIOS name is used:
>>
>> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
>> http://msdn.microsoft.com/en-us/library
101 - 200 of 1946 matches
Mail list logo
