Add support for Python 3.x #1

mrry · 2015-11-09T14:21:11Z

Currently we only support Python 2.7, but we should support Python 3.

girving · 2015-11-09T14:24:41Z

Main things this involves: print -> print(), handle __floordiv__ / __truediv__ / __div__ correctly.

cdnsteve · 2015-11-09T15:01:33Z

👍 to this issue

dvbuntu · 2015-11-09T15:30:56Z

👍

ashwin31 · 2015-11-09T16:36:05Z

👍

joestepp · 2015-11-09T17:17:10Z

👍

girving · 2015-11-09T17:22:09Z

We're working on it.

kevinaloys · 2015-11-09T21:57:45Z

Python 3 is a must have. 👍

mgcdanny · 2015-11-09T22:11:47Z

How do we contribute towards python3 support? Are there any specific tickets open? Is there a python3 development branch?

cdnsteve · 2015-11-09T22:56:17Z

@mgcdanny seems they require contributors to sign an agreement first.
https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md

MikalaiDrabovich · 2015-11-09T23:30:12Z

👍

girving · 2015-11-10T00:12:35Z

I'm running futurize on the code at the moment; once that's done it'll be easier to parallelize the remaining work. So far futurize --stage1 is checked in and I'm working through futurize --stage2 now (checking each of our divisions very carefully :)).

Unfortunately our contribution process needs a bit of improvement (we're working on streamlining it), but I'll see if there are natural chunks of work to break off and ask for help in fixing once the initial futurize push is done. Before that it's tricky to parallelize.

The only non-obvious questions (so far) are what to do with unicode and where. Cc'ing @mrry since he was taking a look at that. Most of the "names" for things, such as names for ops and names for tensors in a graph, are already restricted to be roughly alphanumeric, so hopefully we should be able to leave them as C++ string while still accepting unicode input from Python.

girving · 2015-11-10T00:13:28Z

Also, question for people that have done such conversions before / recently: is six still the recommended way to make code transparently support both? In particular, we need stuff like xrange and iteritems as symbols that exist in both 2.7 and 3.x.

madisonmay · 2015-11-10T00:21:36Z

@girving I would follow the guide written by python3 core dev Brett Cannon: https://docs.python.org/3.5/howto/pyporting.html. He's been heavily involved with the push to move existing libs to python3.

girving · 2015-11-10T00:26:27Z

@madisonmay: Thanks, should have asked you earlier. Modernize probably would have been a better choice, since after reading that page I am essentially taking the output of futurize and then rewriting it into what modernize might have already spit out. Mostly done with that phase, though, so I'll probably just finish it up using futurize.

For the record: futurize --stage was mostly print_function and a few other safe trivialities. I'll write a detailed comment on what futurize --stage2 involved for us once I'm done with it (still in the middle of reading diffs).

yuncliu · 2015-11-10T09:18:37Z

+1

Peque · 2015-11-10T09:41:56Z

I think it is pretty clear that there are many people interested in this issue. However, I would suggest users to use the Subscribe button instead of adding a new 👍.

This way developers (and all subscribed users) can get notifications on useful future updates. 😉

PS: If you already posted a 👍 you might as well consider removing it to keep the discussion cleaner.

girving · 2015-11-10T17:16:27Z

Thank you @Peque! It would be great if further comments were limited to technical discussions about Python 3 support.

goodmami · 2015-11-11T22:36:59Z

From the README:

The TensorFlow Python API currently requires Python 2.7:
we are working on adding support for Python 3.0.

If you require 2.7 for the 2.X line, then why restrict yourselves to 3.0 (which was released about the time of 2.6)? If you target 3.3+, then you'll save yourselves a lot of headache, especially if you're using u'あ' unicode strings. (also see unicode_literals).

And 👍 for six for more complicated things.

vrv · 2015-11-11T22:38:03Z

Sorry, I meant Python 3, not 3.0 -- was in a rush to fix :P. I'll fix this today

girving · 2015-11-11T22:57:46Z

@goodmami: Yes, we will likely only support 3.3+, possibly 3.4+ (I'm not sure what the differences are, but will look that up). I also changed the issue title.

jli05 · 2015-11-11T23:01:22Z

I'd really like you support from 3.3 up to the latest release of Python (currently 3.5; then 4.0 in the future). This piece of software is going to be the heart of many things in human life in the future.

girving · 2015-11-12T00:39:10Z

@jli05: https://docs.python.org/3/whatsnew/3.4.html makes it look like supporting 3.3 won't be any harder than 3.4, so we should be good to go. It is possible our internal tests will be run only in 3.4 (and 2.7), but if anything ever breaks we'll be happy to accept patches.

6iloveyou · 2015-11-12T12:48:21Z

@girving now this version support python3.4 ??

Imported from GitHub PR openxla/xla#7751 Due to fast accumulation being turned on in the forward mode, the cublasLt fp8 gemm with gelu epilogue can efficiently operate with a fused kernel. Compared against the XLA-generated gelu kernel on H100, the performance demonstrates some improvement for size of [8192, 4096] x [4096, 16384] + gelu: Execution time for matmul using cublasLt and gelu (XLA): 1.28ms Execution time for matmul_gelu using cublasLt: 1.25ms Copybara import of the project: -- e8abce3b41f68cae1bb625cdecd5885413a0781d by Shu Wang <shuw@nvidia.com>: Support cublasLt Fp8 Approx Gelu epilogue fusion. -- 818127cf582af7ceba014d88bdf027857fc8f0e5 by shuw <shuw@nvidia.com>: Remove F32 check -- 5ce3108a9bc8459e20456d23a3ae493ef7a6a387 by shuw <shuw@nvidia.com>: Improve based on review #1 Merging this change closes #7751 PiperOrigin-RevId: 591236441

Signed-off-by: Ritul Jasuja <ritul.jasuja@intel.com>

…execution scope Instead of always constructing while operation conditional in the default scope use the scope of a while operation itself. This generates correct CUDA graph: https://gist.github.com/ezhulenev/a84192fe8b46a4bf1a934a8baa08ea60 Memeset operation launched in a scope #1 is not synchronized with initial condition handle update PiperOrigin-RevId: 609742672

PiperOrigin-RevId: 629795760

PiperOrigin-RevId: 629853006

… to Initialize() Imported from GitHub PR openxla/xla#12228 The first time that a NormThunk is executed, it will build a cudnn execution plan. This build step can hang if a NCCL collective is running at the same time. To fix this, I've moved the build step to take place during thunk initialization. We only observe this hang when using cudnn 9. Here's a backtrace from the hang that will be fixed: ``` Thread 585 (Thread 0x7fb9391ff640 (LWP 41364) "main.py"): #0 0x00007fd3d17cffd9 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fd3d17da24f in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fd070967dfe in ?? () from /lib/x86_64-linux-gnu/libcuda.so.1 #3 0x00007fd0709c928a in ?? () from /lib/x86_64-linux-gnu/libcuda.so.1 #4 0x00007f1970d76102 in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #5 0x00007f1970f2c999 in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #6 0x00007f1970a7d4ab in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #7 0x00007f1970d0a9cb in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #8 0x00007fce60b2a98c in cudnn::backend::ExecutionPlan::finalize_internal() () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #9 0x00007fce60aefbb1 in cudnn::backend::Descriptor::finalize() () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #10 0x00007fce60b15bec in cudnnBackendFinalize () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #11 0x00007fd2521b8f39 in cudnn_frontend::ExecutionPlanBuilder_v8::build() () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #12 0x00007fd2521734ba in stream_executor::gpu::(anonymous namespace)::GetExecPlanFromHeuristics(cudnn_frontend::OperationGraph_v8&&, stream_executor::gpu::(anonymous namespace)::CudnnHandle const&, bool) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #13 0x00007fd25216ff9b in stream_executor::gpu::CudnnSupport::NormRunnerFromDesc(stream_executor::Stream*, stream_executor::dnn::AlgorithmDesc const&, stream_executor::dnn::NormKind, double, stream_executor::dnn::TensorDescriptor const&, stream_executor::dnn::TensorDescriptor const&, stream_executor::dnn::TensorDescriptor const&, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #14 0x00007fd24e36b88b in stream_executor::dnn::NormOp::RunnerFromAlgorithmDesc(stream_executor::dnn::AlgorithmDesc const&, stream_executor::dnn::NormOp::Config, stream_executor::Stream*) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #15 0x00007fd24e36ae37 in stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}::operator()() const () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #16 0x00007fd24e36adbc in void absl::lts_20230802::base_internal::CallOnceImpl<stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}>(std::atomic<unsigned int>*, absl::lts_20230802::base_internal::SchedulingMode, stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}&&) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #17 0x00007fd24e36a9bd in stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #18 0x00007fd24e369d29 in xla::gpu::RunGpuNorm(xla::gpu::GpuNormConfig const&, stream_executor::DeviceMemoryBase const&, stream_executor::DeviceMemoryBase const&, stream_executor::DeviceMemoryBase const&, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, stream_executor::DeviceMemoryBase const&, stream_executor::Stream*, xla::gpu::RunNormOptions) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #19 0x00007fd24e368be6 in xla::gpu::NormThunk::ExecuteOnStream(xla::gpu::Thunk::ExecuteParams const&) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so ``` Copybara import of the project: -- f53533087ba1ddcf65ad7cc6268ee89de4690d15 by Trevor Morris <tmorris@nvidia.com>: Fix hang with cudnn layer norm by moving cudnn init to Initialize() Merging this change closes #12228 FUTURE_COPYBARA_INTEGRATE_REVIEW=openxla/xla#12228 from trevor-m:tmorris-norm-init f53533087ba1ddcf65ad7cc6268ee89de4690d15 PiperOrigin-RevId: 633207155

… to Initialize() Imported from GitHub PR openxla/xla#12228 The first time that a NormThunk is executed, it will build a cudnn execution plan. This build step can hang if a NCCL collective is running at the same time. To fix this, I've moved the build step to take place during thunk initialization. We only observe this hang when using cudnn 9. Here's a backtrace from the hang that will be fixed: ``` Thread 585 (Thread 0x7fb9391ff640 (LWP 41364) "main.py"): #0 0x00007fd3d17cffd9 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fd3d17da24f in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fd070967dfe in ?? () from /lib/x86_64-linux-gnu/libcuda.so.1 #3 0x00007fd0709c928a in ?? () from /lib/x86_64-linux-gnu/libcuda.so.1 #4 0x00007f1970d76102 in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #5 0x00007f1970f2c999 in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #6 0x00007f1970a7d4ab in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #7 0x00007f1970d0a9cb in ?? () from /lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.1.0 #8 0x00007fce60b2a98c in cudnn::backend::ExecutionPlan::finalize_internal() () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #9 0x00007fce60aefbb1 in cudnn::backend::Descriptor::finalize() () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #10 0x00007fce60b15bec in cudnnBackendFinalize () from /lib/x86_64-linux-gnu/libcudnn_graph.so.9.1.0 #11 0x00007fd2521b8f39 in cudnn_frontend::ExecutionPlanBuilder_v8::build() () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #12 0x00007fd2521734ba in stream_executor::gpu::(anonymous namespace)::GetExecPlanFromHeuristics(cudnn_frontend::OperationGraph_v8&&, stream_executor::gpu::(anonymous namespace)::CudnnHandle const&, bool) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #13 0x00007fd25216ff9b in stream_executor::gpu::CudnnSupport::NormRunnerFromDesc(stream_executor::Stream*, stream_executor::dnn::AlgorithmDesc const&, stream_executor::dnn::NormKind, double, stream_executor::dnn::TensorDescriptor const&, stream_executor::dnn::TensorDescriptor const&, stream_executor::dnn::TensorDescriptor const&, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>, std::optional<stream_executor::dnn::TensorDescriptor>) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #14 0x00007fd24e36b88b in stream_executor::dnn::NormOp::RunnerFromAlgorithmDesc(stream_executor::dnn::AlgorithmDesc const&, stream_executor::dnn::NormOp::Config, stream_executor::Stream*) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #15 0x00007fd24e36ae37 in stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}::operator()() const () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #16 0x00007fd24e36adbc in void absl::lts_20230802::base_internal::CallOnceImpl<stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}>(std::atomic<unsigned int>*, absl::lts_20230802::base_internal::SchedulingMode, stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*)::{lambda()#1}&&) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #17 0x00007fd24e36a9bd in stream_executor::dnn::LazyOpRunner<stream_executor::dnn::NormOp>::GetOrCreateRunner(stream_executor::dnn::NormOp::Config, stream_executor::Stream*) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #18 0x00007fd24e369d29 in xla::gpu::RunGpuNorm(xla::gpu::GpuNormConfig const&, stream_executor::DeviceMemoryBase const&, stream_executor::DeviceMemoryBase const&, stream_executor::DeviceMemoryBase const&, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, std::optional<stream_executor::DeviceMemoryBase>, stream_executor::DeviceMemoryBase const&, stream_executor::Stream*, xla::gpu::RunNormOptions) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so #19 0x00007fd24e368be6 in xla::gpu::NormThunk::ExecuteOnStream(xla::gpu::Thunk::ExecuteParams const&) () from /usr/local/lib/python3.10/dist-packages/jaxlib/xla_extension.so ``` Copybara import of the project: -- f53533087ba1ddcf65ad7cc6268ee89de4690d15 by Trevor Morris <tmorris@nvidia.com>: Fix hang with cudnn layer norm by moving cudnn init to Initialize() Merging this change closes #12228 PiperOrigin-RevId: 633220207

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% Reverts 162f116 PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% FUTURE_COPYBARA_INTEGRATE_REVIEW=openxla/xla#15444 from eaplatanios:u/eaplatanios/cpp-17-fixes 73f3cd7e0135ec05c97595f795ec318fb635bd32 PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% FUTURE_COPYBARA_INTEGRATE_REVIEW=#65125 from tensorflow:LakshmiKalaKadali-patch-6 ea8f04f PiperOrigin-RevId: 657693426

name old cpu/op new cpu/op delta BM_SelectAndScatterF32/128/process_time 889µs ± 1% 740µs ± 3% -16.70% BM_SelectAndScatterF32/256/process_time 3.64ms ± 2% 3.00ms ± 1% -17.64% BM_SelectAndScatterF32/512/process_time 15.3ms ± 1% 13.1ms ± 3% -14.61% PiperOrigin-RevId: 658063846

girving self-assigned this Nov 9, 2015

teamdandelion added the languages label Nov 9, 2015

ihsw mentioned this issue Nov 9, 2015

is a Python 3 support coming soon ? #39

Closed

scottclowe mentioned this issue Nov 10, 2015

Support for python 3 #104

Closed

arimwilson mentioned this issue Nov 11, 2015

segmentation fault when running convolutional.py #79

Closed

girving changed the title ~~Add support for Python 3~~ Add support for Python 3.x Nov 11, 2015

leondz mentioned this issue Nov 12, 2015

Add support for LSTM leondz/entity_recognition#10

Open

vbenni pushed a commit to vbenni/tensorflow that referenced this issue Dec 27, 2023

Refactor operations module tensorflow#1

08d6f72

Signed-off-by: Ritul Jasuja <ritul.jasuja@intel.com>

ldbrouwer mentioned this issue Feb 26, 2024

Micro_Speech error on Sparkfun Edge when using new model #62999

Closed

copybara-service bot pushed a commit that referenced this issue May 1, 2024

[xla:cpu] NFC: Remove deprecated XLA:CPU mlir based codegen part #1

fed017a

PiperOrigin-RevId: 629795760

copybara-service bot mentioned this issue May 1, 2024

[xla:cpu] NFC: Remove deprecated XLA:CPU mlir based codegen part #1 #66795

Closed

copybara-service bot pushed a commit that referenced this issue May 1, 2024

[xla:cpu] NFC: Remove deprecated XLA:CPU mlir based codegen part #1

fafd046

PiperOrigin-RevId: 629795760

copybara-service bot pushed a commit that referenced this issue May 1, 2024

[xla:cpu] NFC: Remove deprecated XLA:CPU mlir based codegen part #1

993d765

PiperOrigin-RevId: 629853006

aurbital mentioned this issue Jun 15, 2024

protobuf fatal error in Tensorflow 2.16.1 on macos M1 #64507

Closed

ramonhollands mentioned this issue Jun 30, 2024

Tflite model fails on Android GPU delegate due to 'null pointer dereference' #70664

Open

copybara-service bot mentioned this issue Jul 31, 2024

[xla:cpu] Optimize ThunkExecutor::Execute part #1 #72864

Merged

Reyadeyat mentioned this issue Oct 7, 2024

Bazel installer not run on recent Bazel version, kindly provide widly accepted CMake installer #77176

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for Python 3.x #1

Add support for Python 3.x #1

mrry commented Nov 9, 2015

girving commented Nov 9, 2015

cdnsteve commented Nov 9, 2015

dvbuntu commented Nov 9, 2015

ashwin31 commented Nov 9, 2015

joestepp commented Nov 9, 2015

girving commented Nov 9, 2015

kevinaloys commented Nov 9, 2015

mgcdanny commented Nov 9, 2015

cdnsteve commented Nov 9, 2015

MikalaiDrabovich commented Nov 9, 2015

girving commented Nov 10, 2015

girving commented Nov 10, 2015

madisonmay commented Nov 10, 2015

girving commented Nov 10, 2015

yuncliu commented Nov 10, 2015

Peque commented Nov 10, 2015

girving commented Nov 10, 2015

goodmami commented Nov 11, 2015

vrv commented Nov 11, 2015

girving commented Nov 11, 2015

jli05 commented Nov 11, 2015

girving commented Nov 12, 2015

6iloveyou commented Nov 12, 2015

Add support for Python 3.x #1

Add support for Python 3.x #1

Comments

mrry commented Nov 9, 2015

girving commented Nov 9, 2015

cdnsteve commented Nov 9, 2015

dvbuntu commented Nov 9, 2015

ashwin31 commented Nov 9, 2015

joestepp commented Nov 9, 2015

girving commented Nov 9, 2015

kevinaloys commented Nov 9, 2015

mgcdanny commented Nov 9, 2015

cdnsteve commented Nov 9, 2015

MikalaiDrabovich commented Nov 9, 2015

girving commented Nov 10, 2015

girving commented Nov 10, 2015

madisonmay commented Nov 10, 2015

girving commented Nov 10, 2015

yuncliu commented Nov 10, 2015

Peque commented Nov 10, 2015

girving commented Nov 10, 2015

goodmami commented Nov 11, 2015

vrv commented Nov 11, 2015

girving commented Nov 11, 2015

jli05 commented Nov 11, 2015

girving commented Nov 12, 2015

6iloveyou commented Nov 12, 2015