Re: ANN: PyDTLS
This sounds exciting. Are you considering a Python 3 port? It might make a
nice demo of PEP 3156.
On Monday, January 7, 2013, rbit wrote:
> I would like to announce Datagram Transport Layer Security for
> Python. From the top of the project README:
>
> PyDTLS brings Datagram Transport Layer Security (DTLS - RFC 6347:
> http://tools.ietf.org/html/rfc6347) to the Python environment. In a
> nutshell, DTLS brings security (encryption, server authentication,
> user authentication, and message authentication) to UDP datagram
> payloads in a manner equivalent to what SSL/TLS does for TCP stream
> content.
>
> DTLS is now very easy to use in Python. If you're familiar with the
> ssl module in Python's standard library, you already know how. All it
> takes is passing a datagram/UDP socket to the *wrap_socket* function
> instead of a stream/TCP socket. Here's how one sets up the client side
> of a connection:
>
> import ssl
> from socket import socket, AF_INET, SOCK_DGRAM
> from dtls import do_patch
> do_patch()
> sock = ssl.wrap_socket(socket(AF_INET, SOCK_DGRAM))
> sock.connect(('foo.bar.com', 1234))
> sock.send('Hi there')
>
> The project is hosted at https://github.com/rbit/pydtls, and licensed
> under
> the Apache license 2.0. PyPI has packages. I can be reached
> at code AT liquibits DOT com for questions, feedback, etc.
>
> http://pypi.python.org/pypi/Dtls/0.1.0";>Dtls 0.1.0 -
> Datagram Transport Layer Security for Python. (07-Jan-13)
> --
> http://mail.python.org/mailman/listinfo/python-announce-list
>
> Support the Python Software Foundation:
> http://www.python.org/psf/donations/
>
--
--Guido van Rossum (python.org/~guido)
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyDTLS
On Tue, Jan 8, 2013 at 8:39 PM, rbit wrote:
> Thank you. I will gladly port to Python 3 if there is interest from
> the community.
Python 3 is where it's at! :-)
> Regarding PEP 3156: asynchronous use of unreliable network protocols
> makes for an interesting use case. In particular, it forces
> applications to deal with packet loss under some circumstances.
But don't you have to deal with that when doing synchronous I/O as
well? It's a datagram protocol after all.
> One
> such situation occurs during DTLS's handshaking phase: if no response
> is received from the peer after some period of time, we must assume
> that our most recent datagram has been lost, and so we need to
> retransmit.
Is this something the transport can handle, or does the protocol (and
hence the application) need to be involved here?
> The event loop interface as outlined in the PEP makes this
> a bit difficult (as did the asyncore module). One possible way to make
> things easier would be by adding two parameters to add_reader: a
> callable to retrieve the current timeout, and a callable that is
> invoked if that timeout expires before the descriptor becomes
> readable. Each loop iteration would then collect all given timeouts,
> and pass the minimum of that set to whatever polling facility it
> invokes. If that timeout expires, the corresponding timeout handler
> would be invoked prior to the next loop iteration.
Hm, this would add a fair amount of complexity to the event loop. It's
true that I don't have the complete story for timeouts yet, but I am
hopeful that things like this can be implemented by using call_later()
with some callback that does the retransmit (and resets some internal
state), and cancelling that callback whenever a packet is received
(i.e. in the protocol's datagram_received() method).
> The PEP also considers only stream transports when referring to
> "transport." Datagram transports do not, for example, have the
> property that calling t.write(b'abc'); t.write(b'def') is equivalent
> to calling t.write(b'abcdef').
Yeah, obviously this invariant only applies to stream protocols. The
PEP currently doesn't really specify datagram support (it's just in
the Open Issues section).
> I'm not sure what sort of impact this
> omission of datagram transports has for an implementation. Though I
> would certainly like to see datagram transports be treated as
> first-class citizens, despite not being nearly used as often as stream
> transports. I would hope that an implementer of, say, RTP over UDP,
> can tie into the same event loop as someone implementing a
> single-process, single-threaded Web server.
Yeah, at the level of the eventloop proper (the APIs that deal with
callbacks, not futures, transports and protocols) datagrams won't be a
problem. There will have to be separate specifications for the
transport and protocol interfaces used with datagrams.
> Implementing DTLS as a tulip transport sounds interesting. Is the
> tulip package available somewhere so that I can try it out?
Absolutely -- it is very much in flux, but you can check out the
latest source from http://code.google.com/p/tulip/source/checkout
using Mercurial.
--Guido
> Ray
>
> On Tue, Jan 8, 2013 at 6:53 AM, Guido van Rossum wrote:
>> This sounds exciting. Are you considering a Python 3 port? It might make a
>> nice demo of PEP 3156.
>>
>>
>> On Monday, January 7, 2013, rbit wrote:
>>>
>>> I would like to announce Datagram Transport Layer Security for
>>> Python. From the top of the project README:
>>>
>>> PyDTLS brings Datagram Transport Layer Security (DTLS - RFC 6347:
>>> http://tools.ietf.org/html/rfc6347) to the Python environment. In a
>>> nutshell, DTLS brings security (encryption, server authentication,
>>> user authentication, and message authentication) to UDP datagram
>>> payloads in a manner equivalent to what SSL/TLS does for TCP stream
>>> content.
>>>
>>> DTLS is now very easy to use in Python. If you're familiar with the
>>> ssl module in Python's standard library, you already know how. All it
>>> takes is passing a datagram/UDP socket to the *wrap_socket* function
>>> instead of a stream/TCP socket. Here's how one sets up the client side
>>> of a connection:
>>>
>>> import ssl
>>> from socket import socket, AF_INET, SOCK_DGRAM
>>> from dtls import do_patch
>>> do_patch()
>>> sock = ssl.wrap_socket(socket(AF_INET, SOCK_DGRAM))
>>> sock.connect(('foo.bar.com', 1234))
>>> sock.send('Hi there')
>>>
>>> The
Re: ANN: PyDTLS
On Tue, Jan 8, 2013 at 11:38 PM, rbit wrote: > On Tue, Jan 8, 2013 at 9:09 PM, Guido van Rossum wrote: >> But don't you have to deal with that when doing synchronous I/O as >> well? It's a datagram protocol after all. > > No: when dealing with blocking sockets, the OpenSSL library activates its > own retransmission timers, and the application never becomes aware of > whether timeouts occurred. Since OpenSSL can't do this in the the case of > non-blocking sockets, it becomes the application's problem to call back into > OpenSSL at some point in the future (the very same time for which OpenSSL > would have set its own timeout had the socket been blocking). OpenSSL > exports functions DTLSv1_get_timeout and DTLSv1_handle_timeout to > applications to address this case. The timeouts start at one second, and > double for each encountered timeout, until the timeout ceiling of one > minutes is reached. I'm using the term "application" here for any code that > uses the OpenSSL library, but is not part of it. Got it. >>> One >>> such situation occurs during DTLS's handshaking phase: if no response >>> is received from the peer after some period of time, we must assume >>> that our most recent datagram has been lost, and so we need to >>> retransmit. >> >> Is this something the transport can handle, or does the protocol (and >> hence the application) need to be involved here? > > Given my current understanding of the PEP, I think this can be handled in > the transport. Maybe there's some pitfall here that I can't quite see yet - > even more reason for me to try to implement it. Yes -- I won't considered the PEP ready for acceptance until several people have successfully implemented new protocols using it and agree that they can do everything they need. (I want to get started with a decent HTTP client and server myself.) >>> The event loop interface as outlined in the PEP makes this >>> a bit difficult (as did the asyncore module). One possible way to make >>> things easier would be by adding two parameters to add_reader: a >>> callable to retrieve the current timeout, and a callable that is >>> invoked if that timeout expires before the descriptor becomes >>> readable. Each loop iteration would then collect all given timeouts, >>> and pass the minimum of that set to whatever polling facility it >>> invokes. If that timeout expires, the corresponding timeout handler >>> would be invoked prior to the next loop iteration. >> >> Hm, this would add a fair amount of complexity to the event loop. It's >> true that I don't have the complete story for timeouts yet, but I am >> hopeful that things like this can be implemented by using call_later() >> with some callback that does the retransmit (and resets some internal >> state), and cancelling that callback whenever a packet is received >> (i.e. in the protocol's datagram_received() method). > > Yes, ok, I can see how that could work, too. I thought that it might make > sense to centralize handling timeouts in the event loop in order to prevent > proliferation in the transports (since there are multiple event loop > implementations, perhaps a mix-in would be good?). A mix-in for what? Each event loop presumably already has its own timer implementation; call_later() and call_repeatedly() are supported in one way or another by all other event loops I'm aware of. We'll have to have more experience with writing transports and protocols before we'll know what is really missing. > I think one will want to > contain handshake (vs. application data) timeout handling at least to the > transport, though, and not let it spill over into various protocols. I'm not > sure yet where the right place is for cancelling a timeout callback. This seems pretty unique to your TLS-over-UDP use case. I am quite sure that you can write a transport that suits your purpose with just the socket, callback and timer primitives in the PEP. >>> Implementing DTLS as a tulip transport sounds interesting. Is the >>> tulip package available somewhere so that I can try it out? >> >> Absolutely -- it is very much in flux, but you can check out the >> latest source from http://code.google.com/p/tulip/source/checkout >> using Mercurial. > > All right, thanks, I'll check it out. Looking forward to your feedback! -- --Guido van Rossum (python.org/~guido) -- http://mail.python.org/mailman/listinfo/python-list
Re: Jython 2.7 alpha1 is out!
Congrats Frank! I reposted this on my G+ account and got some interesting comments. https://plus.google.com/u/0/115212051037621986145/posts/ifyqW3JBd3a There's got to be a way for you to make money off the Oracle connection! (PS: It would have been nice if there was an announcement page on the Jython website/wiki instead of having to link to a mailing list archive page. :-) --Guido On Thu, May 17, 2012 at 1:56 PM, fwierzbi...@gmail.com wrote: > On behalf of the Jython development team, I'm pleased to announce that > Jython 2.7 alpha1 is available for download here: > http://sourceforge.net/projects/jython/files/jython-dev/2.7.0a1/jython_installer-2.7a1.jar/downloaddownload. > See the installation instructions here: > http://wiki.python.org/jython/InstallationInstructions > > I'd like to thank Adconion Media Group for sponsoring my work on > Jython 2.7. I'd also like to thank the many contributors to Jython. > > Jython 2.7 alpha1 implements much of the functionality introduced by > CPython 2.6 and 2.7. There are still some missing features, in > particular bytearray and the io system are currently incomplete. > > Please report any bugs here: http://bugs.jython.org/ Thanks! > > -Frank > -- > http://mail.python.org/mailman/listinfo/python-announce-list > > Support the Python Software Foundation: > http://www.python.org/psf/donations/ -- --Guido van Rossum (python.org/~guido) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull wrote: > Gabriel AHTUNE writes: > > So can be done with this syntax: > > > > > x = firstpart * secondpart + #line breaks here > > > anotherpart + #continue > > > stillanother #continue on. > > > > after a "+" operator the line is clearly not finished yet. > > Sure, but IIRC one design principle of Python is that the keyword that > denotes the syntax should be the first thing on the line, making it > easy to scan down the left side of the code to see the syntactic > structure. The required indentation of the controlled suite also > helps emphasize that keyword. That's true for *statements* (except assignments and calls). > Analogously, if operators are going to denote continuation, they > should come first on the line. That doesn't follow. My preferred style is actually to put the binary operator at the end of the line. This also matches the prevailing style for breaking lines after commas (a comma can be seen as a kind of binary operator). > I just don't think this idea is going anywhere. Explicit continuation > with backslash or implicit continuation of parenthesized expressions > is just not that heavy a price to pay. Perhaps historically some of > these ideas could have been implemented, but now they're just going to > confuse a host of editors and code analysis tools. Totally agreed that this isn't going to happen. -- --Guido van Rossum (python.org/~guido) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Strange occasional marshal error
On Thu, Mar 3, 2011 at 9:40 AM, MRAB wrote:
> On 03/03/2011 15:09, Graham Stratton wrote:
>>
>> On Mar 2, 3:01 pm, Graham Stratton wrote:
>>>
>>> We are using marshal for serialising objects before distributing them
>>> around the cluster, and extremely occasionally a corrupted marshal is
>>> produced. The current workaround is to serialise everything twice and
>>> check that the serialisations are the same. On the rare occasions that
>>> they are not, I have dumped the files for comparison. It turns out
>>> that there are a few positions within the serialisation where
>>> corruption tends to occur (these positions seem to be independent of
>>> the data of the size of the complete serialisation). These are:
>>>
>>> 4 bytes starting at 548867 (0x86003)
>>> 4 bytes starting at 4398083 (0x431c03)
>>> 4 bytes starting at 17595395 (0x10c7c03)
>>> 4 bytes starting at 19794819 (0x12e0b83)
>>> 4 bytes starting at 22269171 (0x153ccf3)
>>> 2 bytes starting at 25052819 (0x17e4693)
>>> 3 bytes starting at 28184419 (0x1ae0f63)
>>
>> I modified marshal.c to print when it extends the string used to write
>> the marshal to. This gave me these results:
>>
>>>>> s = marshal.dumps(list((i, str(i)) for i in range(140)))
>>
>> Resizing string from 50 to 1124 bytes
>> Resizing string from 1124 to 3272 bytes
>> Resizing string from 3272 to 7568 bytes
>> Resizing string from 7568 to 16160 bytes
>> Resizing string from 16160 to 33344 bytes
>> Resizing string from 33344 to 67712 bytes
>> Resizing string from 67712 to 136448 bytes
>> Resizing string from 136448 to 273920 bytes
>> Resizing string from 273920 to 548864 bytes
>> Resizing string from 548864 to 1098752 bytes
>> Resizing string from 1098752 to 2198528 bytes
>> Resizing string from 2198528 to 4398080 bytes
>> Resizing string from 4398080 to 8797184 bytes
>> Resizing string from 8797184 to 17595392 bytes
>> Resizing string from 17595392 to 19794816 bytes
>> Resizing string from 19794816 to 22269168 bytes
>> Resizing string from 22269168 to 25052814 bytes
>> Resizing string from 25052814 to 28184415 bytes
>> Resizing string from 28184415 to 31707466 bytes
>>
>> Every corruption point occurs exactly three bytes above an extension
>> point (rounded to the nearest word for the last two). This clearly
>> isn't a coincidence, but I can't see where there could be a problem.
>> I'd be grateful for any pointers.
This bug report doesn't mention the Python version nor the platform --
it could in theory be a bug in the platform compiler or memory
allocator. It would also be nice to provide the test program that
reproduces the issue. It would also be useful to start tracking it in
the issue tracker at bugs.python.org
Assuming it's 3.2, I would audit _PyBytes_Resize() and whatever it
uses -- if your hunch is right and there is a problem with resizing
that's where it's done.
> I haven't found the cause, but I have found something else I'm
> suspicious of in the source for Python 3.2.
>
> In marshal.c there's a function "w_object", and within that function is
> this:
>
> else if (PyAnySet_CheckExact(v)) {
> PyObject *value, *it;
>
> if (PyObject_TypeCheck(v, &PySet_Type))
> w_byte(TYPE_SET, p);
> else
> w_byte(TYPE_FROZENSET, p);
>
> "w_byte" is a macro which includes an if-statement, not a function.
> Doesn't it need some braces? (There's are braces in the other places
> they're needed.)
That macro looks fine to me; looking at the definition of w_byte() it
has matched if/else clauses:
#define w_byte(c, p) if (((p)->fp)) putc((c), (p)->fp); \
else if ((p)->ptr != (p)->end) *(p)->ptr++ = (c); \
else w_more(c, p)
Although traditionally, just to be sure, we've enclosed similar macros
inside do { ... } while (0). Also it would be nice to call out its
macro-status by renaming it to W_BYTE -- I suppose at one point in the
past it was a plain function...
--
--Guido van Rossum (python.org/~guido)
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Small lament...
A bit late, this reached my inbox: https://peternorvig.medium.com/new-python-operators-9f31b56ddcc7 On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro wrote: > Just wanted to throw this out there... I lament the loss of waking up on > April 1st to see a creative April Fool's Day joke on one or both of these > lists, often from our FLUFL... Maybe such frivolity still happens, just not in > the Python ecosystem? I know you can still import "this" or > "antigravity", but those are now old (both introduced before 2010). When > was the last time a clever easter egg was introduced or an April Fool's Day > joke played? > > ¯\_(ツ)_/¯ > > Skip > > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Python 0.9.1
Awesome, Skip!
Was there a date somewhere? I can't recall if this would have been the
first open source release (from just about 30 years ago, sometime in
February 1991) or some time later in the same year?
On Tue, Feb 16, 2021 at 1:57 PM Skip Montanaro
wrote:
> A note to webmas...@python.org from an astute user named Hiromi in Japan*
> referred
> us to Guido's shell archives for the 0.9.1 release from 1991. As that
> wasn't listed in the historical releases README file:
>
> https://legacy.python.org/download/releases/src/README
>
> I pulled the shar files (and a patch), then made a few tweaks to get it to
> build:
>
> % ./python
> >>> print 'hello world!'
> hello world!
> >>> import sys
> >>> dir(sys)
> ['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin',
> 'stdout']
> >>> sys.modules
> {'builtin': ; 'sys': ; '__main__': '__main__'>}
> >>> sys.exit(0)
>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>
> There is a new directory named "shar" with the original files, a small
> README file and a compile.patch file between the original code and the
> runnable code.
>
> It was a pleasant diversion for a couple hours. I was tired of shovelling
> snow anyway... Thank you, Hiromi.
>
> Skip
>
> * Hiromi is bcc'd on this note in case he cares to comment. I didn't want
> to publish his email beyond the bounds of the webmaster alias without his
> permission.
>
> ___
> Python-Dev mailing list -- python-...@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-...@python.org/message/VZYELIYAQWUHHGIIEPPJFREDX6F24KMN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Re: Python 0.9.1
On Tue, Feb 16, 2021 at 2:59 PM Senthil Kumaran wrote: > On Tue, Feb 16, 2021 at 1:58 PM Skip Montanaro > wrote: > >> >> I then pushed the result to a Github repo: >> >> https://github.com/smontanaro/python-0.9.1 >> > > Wow. Was white-space not significant in this release of Python? I see the > lack of indentation in the first Python programs. > Indentation most certainly was significant from day 0. I suspect what happened is that these files got busted somehow by the extraction process used by Skip or Hiromi. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Re: Looking for people interested in a Python register virtual machine project
On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro wrote: > I've not attempted to make any changes to calling conventions. It > occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be > merged into a single opcode, but I haven't really thought about that. > Perhaps there's a good reason the method is looked up before the > arguments are pushed onto the stack (call_function()?). In a > register-based VM there's no need to do things in that order. > IIRC the reason is that Python's language reference promises left-to-right evaluation here. So o.m(f()) needs to evaluate o.m (which may have a side effect if o overrides __getattr__) before it calls f(). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASE] Python 3.6.0b1 is now available
Fortunately that page isn't linked from anywhere on the home page AFAIK. If it is, could someone file an issue in the pydotorg tracker? The url is at the bottom of every page. On Wed, Sep 14, 2016 at 3:41 AM, Paul Moore wrote: > On 14 September 2016 at 11:32, Serhiy Storchaka wrote: >> On 13.09.16 02:35, Ned Deily wrote: >>> >>> On behalf of the Python development community and the Python 3.6 release >>> team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1 >>> is the first of four planned beta releases of Python 3.6, the next major >>> release of Python, and marks the end of the feature development phase >>> for 3.6. >> >> >> There is no mention on https://www.python.org/news/. > > The last release mentioned there is 3.4.0rc1... > > Paul > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASE] Python 2.7.15
Simple. I misread "latest" for "last" and was hopeful that no new bugs would need to be fixed between now and 2020. I will post a correction on Twitter now. On Tue, May 1, 2018 at 2:58 AM, Alex Walters wrote: > I've gotten some mixed signals on the status of this release, notably from > the BDFL: > > https://twitter.com/gvanrossum/status/991170064417153025 > "Python 2.7.15 released -- the last 2.7 release!" (and a link to this > thread) > > I was under the impression that 2.7 was being supported until 2020. If > this > is the final release of 2.7, what would "support" constitute? My > assumption > was that the final release of 2.7 would be sometime in 2020 (or much closer > to 2020 than 19 months). > > > -Original Message- > > From: Python-Dev > list=sdamon@python.org> On Behalf Of Benjamin Peterson > > Sent: Tuesday, May 1, 2018 12:10 AM > > To: python-list@python.org; python-annou...@python.org; python- > > d...@python.org > > Subject: [Python-Dev] [RELEASE] Python 2.7.15 > > > > Greetings, > > I'm pleased to announce the immediate availability of Python 2.7.15, the > > latest bug fix release in the senescent Python 2.7 series. > > > > Source and binary downloads may be found on python.org: > > > > https://www.python.org/downloads/release/python-2715/ > > > > Bugs should be reported to https://bugs.python.org/ > > > > The source tarball contains a complete changelog in the Misc/NEWS file. > The > > only change since the release candidate is a fix for undefined C behavior > that > > newer compilers (including GCC 8) have started to exploit. > > > > Users of the macOS binaries should note that all python.org macOS > installers > > now ship with a builtin copy of OpenSSL. Additionally, there is a new > > additional installer variant for macOS 10.9+ that includes a built-in > version of > > Tcl/Tk 8.6. See the installer README for more information. > > > > Happy May, > > Benjamin > > 2.7 release manager > > ___ > > Python-Dev mailing list > > python-...@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- > > list%40sdamon.com > > ___ > Python-Dev mailing list > python-...@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: PyDocs Arabic Translation Started and Call to Interested Parties viz en-ar Speakers
Thank you for taking the lead and good luck with the project! On Wed, Jul 18, 2018 at 11:57 PM Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > Greetings everybody, > > i take this opportunity to announce to the python community that Arabic > translations for the docs have started at > > https://github.com/Abdur-rahmaanJ/py-docs-ar > > as per the PEP written by @JulienPalard and @Mariatta, we are working on > the tutorials (for 3.7). you can view details in the docs mailing list > archive. > > coordinator for this project : myself > > as i have contributed to the french docs, i have cloned the .po french > repo for the Arabic one and modified accordingly > > as per recommedations for coordinators (thanking @Julien for tips) i have > been contacting arab-speaking developers for involvement and announcing the > project. feedbacks were positive with the likes of > > وشكرا لك على المبادرة الجميلة > And thank you for the beautiful initiative > > والله يعطيكم الف عافية > And may Allah/God gives you (literally) thousands of wellness > > however, i've found out that git is a major barrier for translations as > well. many programmers for fun around, they like py, they use it, but few > actually have a github account. must search further. nevertheless they are > willing to translate as much as i want, i am still pondering an appropriate > off-git solution, then merge by me. > > for the past days we have been convening on the keywords, the starting > point of any translation, as, though i know Arabic, i have to cross check > with native speakers as to how they really say it as there are words that > are left untranslated but written in arabic as well as for similar details > > that said, i call to python programmers, in any language to contribute to > translations, as you will by the way know the docs thoroughly. > > and in the case of this mail, a special call for arabic-speaking people to > get involved > > this is a huge task (french still at 29%) but i believe that this will > help programmers around the world to better access such a sleek, candy, > soulful, neat and lovely language, and my way of saying thank you / > contributing back to the community > > your fellow brother in code, > > Abdur-Rahmaan Janhangeer > https://github.com/Abdur-rahmaanJ > Mauritius > -- --Guido (mobile) -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Retrospective of Python compilation efforts
Nice work. On Tue, Dec 24, 2019 at 2:59 AM Paul Sokolovsky wrote: > Hello, > > Over the years, the Python community produced many compiler projects for > the language, second to probably only C and LISP. Majority are of > course of research and proof of concept quality, but there're a number > of quite advanced projects. > > For some time, I was trying to compile a retrospective of these > efforts, formatted as a github "awesome" list: > > https://github.com/pfalcon/awesome-python-compilers > > > Happy holidays, > Paul > -- > Python-announce-list mailing list -- python-announce-l...@python.org > To unsubscribe send an email to python-announce-list-le...@python.org > https://mail.python.org/mailman3/lists/python-announce-list.python.org/ > > Support the Python Software Foundation: > http://www.python.org/psf/donations/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] Thank you Larry Hastings!
Thank you Larry! On Mon, Oct 5, 2020 at 11:39 AM Barry Warsaw wrote: > They say being a Python Release Manager is a thankless job, so the Python > Secret Underground (PSU), which emphatically does not exist, hereby > officially doesn’t thank Larry for his years of diligent service as the > Python 3.4 and 3.5 release manager. > > On the other hand, the Python Steering Council, Python Software > Foundation, and worldwide Python community, all of which emphatically *do* > exist, all extend our heartfelt thanks to Larry for his excellent > stewardship of Python 3.4 and 3.5! > > Python 3.4 and 3.5 were both pivotal releases. While the features of > these two releases are too numerous to mention here, they introduced such > staples as: > > * asyncio > * enum > * pathlib > * async and await keywords > * matrix multiplication operators > * typing and zipapp modules > > and so much more. For details, see: > > * https://docs.python.org/3/whatsnew/3.4.html > * https://docs.python.org/3/whatsnew/3.5.html > > Larry’s first official release of 3.4.0a1 was on 2013-08-03 and his last > Python 3.5.10 release was 2020-09-05. That’s 7 years of exemplary release > managing! > > Larry, from all of us, and from me personally, thank you so much for your > invaluable contributions to Python. Enjoy your retirement! > > Cheers, > -Barry (on behalf of the PSC and PSF) > > ___ > python-committers mailing list -- python-committ...@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committ...@python.org/message/QGIHFU64TBYT56K6M5A5LYTYTSVFKHWQ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] RELEASED Python 2.4 (final)
On Tue, 30 Nov 2004 23:31:34 +1100, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On behalf of the Python development team and the Python community, I'm > happy to announce the release of Python 2.4. Anthony, congratulations with this smooth release! Thanks for all the hard work. Enjoy your beer, I'm celebrating with you in spirit. Thanks also to all the other developers who contributed to this release, and to the many thousands of users who helped with the the beta testing. Let's hope for record downloads, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 2:24 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters wrote: > >> "A potential problem" with .astimezone()'s default is that it _does_ >> create a fixed-offset zone. It's not at all obvious that it should do >> so. First time I saw it, my initial _expectation_ was that it >> "obviously" created a hybrid tzinfo reflecting the system zone's >> actual daylight rules, as various "tzlocal" implementations outside of >> Python do. >> > > The clue should have been that .astimezone() is an instance method and > you don't need to know time to create a hybrid tzinfo. If a Local tzinfo > was available, it could just be passed to the .astimezone() method as an > argument. You would not need .astimezone() to both create a tzinfo and > convert the datetime instance to it. > > Still, I agree that this was a hack and a very similar hack to the one > implemented by pytz. Hopefully once PEP 495 is implemented we will > shortly see "as intended" tzinfos to become more popular. > The repeated claims (by Alexander?) that astimezone() has the power of pytz's localize() need to stop. Those pytz methods work for any (pytz) timezone -- astimezone() with a default argument only works for the local time zone. (And indeed what it does is surprising, except perhaps to pytz users.) -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sat, Sep 12, 2015 at 5:46 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum > wrote: > >> The repeated claims (by Alexander?) that astimezone() has the power of >> pytz's localize() need to stop. > > > Prove me wrong! :-) > > >> Those pytz methods work for any (pytz) timezone -- astimezone() with a >> default argument only works for the local time zone. > > > That's what os.environ['TZ'] = zonename is for. The astimezone() method > works for every timezone installed on your system. Try it - you won't even > need to call time.tzset()! > That's global state. Doesn't count. > (And indeed what it does is surprising, except perhaps to pytz users.) > > > That I agree with. Which makes it even more surprising that I often find > myself and pytz advocates on the opposite sides of the fence. > > Granted, setting TZ is a silly trick, but one simple way to bring a full > TZ database to Python is to allow .astimezone() take a zonename string like > 'Europe/Amsterdam' or 'America/Montevideo' as an argument and act as > os.environ['TZ'] = zonename; t.astimezone() does now, but without messing > with global state. > It might as well be a different method then though. > I made this suggestion before, but I find it inferior to "as intended" > tzinfos. > > The only real claim that I am making is that fictitious fixed offset > timezones are useful and we already have some support for them in stdlib. > The datetime.timezone instances that .astimezone() attaches as tzinfo are > not that different from the instances that are attached by pytz's localize > and normalize methods. > And it has the same defect. > In fact, the only major differences between datetime.timezone instances > and those used by pytz is that pytz's EST and EDT instances know that they > come from America/New_York, while datetime.timezone instances don't. > That's why once you specify America/New_York in localize, your > tzinfo.normalize knows it implicitely, while in the extended .astimezone() > solution you will have to specify it again. This is not a problem when you > only support one local timezone, but comes with a different set of > tradeoffs when you have multiple timezones. > > One advantage of not carrying the memory of the parent zoneinfo in the > fixed offset tzinfo instance is that pickling of datetime objects and their > interchange between different systems becomes simpler. A pickle of a > datetime.timezone instance is trivial - same as that of a tuple of > timedelta and a short string, but if your fixed offset tzinfo carries a > reference to a potentially large zoneinfo structure, you get all kinds of > interesting problems when you share them between systems that have > different TZ databases. > The pickling should be careful to pickle by reference (on the timezone name). That its meaning depends on the tz database is a feature. > In any case, there are three approaches to designing a TZ database > interface in the datetime module: the "as intended" approach, the pytz > approach and the astimezone(zonename:str) approach. The last two don't > require a fold attribute to disambiguate end-of-dst times and the first one > does. With respect to arithmetic, the last two approaches are equivalent: > both timeline and classic arithmetics are possible, but neither is > painless. The "as intended" approach comes with classic arithmetic that > "just works" and encourages the best practice for timeline arithmetic: do > it in UTC. That's why I believe PEP 495 followed by the implementation of > fold-aware "as intended" tzinfos (either within stdlib or by third parties) > is the right approach. > Right. So please focus on this path and don't try to pretend to pytz users that hacks around astimezone() make pytz redundant, because they don't. There are other ways to fix the damage that pytz has done. -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
On Sun, Sep 13, 2015 at 5:24 AM, Laura Creighton wrote: > My question, is whether it will handle Creighton, Saskatchewan, Canada? > Creighton is an odd little place. Like all of Saskatchewan, it is > in the Central time zone, even though you would expect it to be > in the Mountain time zone based on its location on the globe. > The people of Saskatchewan have decided not to adopt Daylight > Savings time. Except for the people of Creighton (and > nearby Denare Beach) -- who _do_ observe Daylight savings time. > > makes for an interesting corner case, one that I remember for > personal (and not economic, or professional) reasons. > Hi Laura! Wouldn't it be sufficient for people in Creighton to set their timezone to US/Central? IIUC the Canadian DST rules are the same as the US ones. Now, the question may remain how do people know what to set their timezone to. But neither pytz nor datetime can help with that -- it is up to the sysadmin. -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
Re: installing python 3
Dear Ashley, Try describing your problem on StackOverflow.com. I'm sure someone there will help you. Good luck! --Guido On Sep 9, 2014 2:27 AM, "Ashley Forman" wrote: > Hello, > My name is Ashley Forman, and I am emailing because I cannot install > python onto my Mac laptop! I have installed Active-TCl 8.5 along with > Python 3.3 and tried with 3.4, and couldn't figure out a solution to my > problem. When I click on IDLE to open, it does not open at all. Therefore, > if you have any information that could help me, then I would really > appreciate it! Thank you! > Best, > Ashley Forman > -- > https://mail.python.org/mailman/listinfo/python-announce-list > > Support the Python Software Foundation: > http://www.python.org/psf/donations/ > -- https://mail.python.org/mailman/listinfo/python-list
Re: How to kill a SocketServer?
[Skip Montanaro] > I stumbled on a somewhat cleaner way to do this using socket timeouts: > > class Server(SocketServer.ThreadingMixIn, SocketServer.TCPServer): > pause = 0.25 > allow_reuse_address = True > > def __init__(self, server_address, RequestHandlerClass): > SocketServer.TCPServer.__init__(self, server_address, > RequestHandlerClass) > self.socket.settimeout(self.pause) > self.serving = 1 > ... > > def serve_forever(self): > while self.serving: > self.handle_request() > > As far as my simple testing went (a trivial little xmlrpc server exposing > only "noop" and "exit" methods), the above worked fine. I was mildly > surprised that I didn't have to catch socket.timeout exceptions. I think this would cause timeouts in the middle of handling request whenever a client is slow. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
For review: PEP 343: Anonymous Block Redux and Generator Enhancements
After many rounds of discussion on python-dev, I'm inviting public comments for PEP 343. Rather than posting the entire PEP text here, I'm inviting everyone to read it on line (http://www.python.org/peps/pep-0343.html) and then post comments on a Wiki page I've created for this purpose (http://wiki.python.org/moin/WithStatement). I think this is a good one; I hope people agree. Its acceptance will obsolete about 4 other PEPs! (A sign that it fulfills a need and that the proposed solution is powerful.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 released as 3.0a1
[Bcc: [EMAIL PROTECTED] The first Python 3000 release is out -- Python 3.0a1. Be the first one on your block to download it! http://python.org/download/releases/3.0/ Excerpts: Python 3000 (a.k.a. "Py3k", and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. This is an ongoing project; the cleanup isn't expected to be complete until 2008. In particular there are plans to reorganize the standard library namespace. The release plan is to have a series of alpha releases in 2007, beta releases in 2008, and a final release in August 2008. The alpha releases are primarily aimed at developers who want a sneak peek at the new langauge, especially those folks who plan to port their code to Python 3000. The hope is that by the time of the final release, many 3rd party packages will already be available in a 3.0-compatible form. More links: * Online docs: http://docs.python.org/dev/3.0/ * What's new: http://docs.python.org/dev/3.0/whatsnew/3.0.html * Source tar ball: http://python.org/ftp/python/3.0/Python-3.0a1.tgz * Windows MSI installer: http://python.org/ftp/python/3.0/python-3.0a1.msi * PEP 3000: http://python.org/dev/peps/pep-3000/ * Issue tracker: http://bugs.python.org/ * Py3k dev list: http://mail.python.org/mailman/listinfo/python-3000/ * Conversion tool for Python 2.x code: http://svn.python.org/view/sandbox/trunk/2to3/ -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
ate
> a 3-⒯ of ✎s would be nice. This would change the line in the above
> from "if comp✎ in ('', '.')⒯:" to "if comp✎ in ('', '.')✎✎2⒯:", which
> I think is a nice win in terms of readability, EIBTI and all that.
>
> (Sidebar: I think the PEP should feature a section on how these new
> type declarations will cut down on mailing list volume and
> documentation size.)
>
> In light of this PEP, PEP 3107's function annotations should be
> rejected. All that hippie feel-good crap about "user-defined
> annotations" and "open-ended semantics" and "no rules, man" was just
> going to get us into trouble. This PEP's more modern conception of
> type annotations give the language a power and expressiveness that my
> PEP could never hope to match.
>
> This is clearly a move in the right direction. +4 billion.
>
> Collin Winter
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] bug in modulus?
This is way above my head. :-) The only requirement *I* would like to see is that for floats that exactly represent ints (or longs for that matter) the result ought of x%y ought to have the same value as the same operation on the corresponding ints (except if the result can't be represented exactly as a float -- I don't know what's best then). We're fixing this for / in Py3k, so passing an int into an algorithm written for floats won't be harmful and won't require defensiev float() casting everywhere. It would be a shame if we *introduced* a new difference between ints and floats for %. --Guido On 5/2/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Andrew Koenig, on the counter intuitive -1e-050 % 2.0 == 2.0 example] > >> I disagree. For any two floating-point numbers a and b, with b != 0, it > >> is always possible to represent the exact value of a mod b as a > >> floating-point number--at least on every floating-point system I have ever > >> encountered. The implementation is not even that difficult. > > [also Andrew] > > Oops... This statement is true for the Fortran definition of modulus (result > > has the sign of the dividend) but not the Python definition (result has the > > sign of the divisor). In the Python world, it's true only when the dividend > > and divisor have the same sign. > > Note that you can have it in Python too, by using math.fmod(a, b) > instead of "a % b". > > IMO, it was a mistake (and partly my fault cuz I didn't whine early) > for Python to try to define % the same way for ints and floats. The > hardware realities are too different, and so are the pragmatics. For > floats, it's actually most useful most often to have both that a % b > is exact and that 0.0 <= abs(a % b) <= abs(b/2). Then the sign of a%b > bears no relationship to the signs of a and b, but for purposes of > modular reduction it yields the result with the smallest possible > absolute value. That's often valuable for floats (e.g., think of > argument reduction feeding into a series expansion, where time to > convergence typically depends on the magnitude of the input and > couldn't care less about the input's sign), but rarely useful for > ints. > > I'd like to see this change in Python 3000. Note that IBM's proposed > standard for decimal arithmetic (which Python's "decimal" module > implements) requires two operations here, one that works like > math.fmod(a, b) (exact and sign of a), and the other as described > above (exact and |a%b| <= |b/2|). Those are really the only sane > definitions for a floating point modulo/remainder. > ___________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] "as" keyword woes
On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <[EMAIL PROTECTED]> wrote: [...] > There, I assert that 'object.as(class_reference)' is the simplest and > most elegant generalization of this widely-used convention. Indeed, it > is the only obvious concise answer, if you are limited to using methods > for casting. Well, that's too bad, as 'as' is now a reserved word. > Although there are other valid domain-specific uses for "as" as either a > local variable or attribute names (e.g. systematic naming: as, bs, cs), > those aren't nearly as important compared to "as" being available as the > name of a generalized casting method -- one that is now strictly denied > to users of Python 2.6 and 3. If you had brought this up 5-10 years ago when we first introduced 'as' as a semi-keyword (in the import statement) we might have been able to avert this disaster. As it was, nobody ever brought this up AFICR, so I don't think it's *that* obvious. > As someone somewhat knowledgable of how parsers work, I do not > understand why a method/attribute name "object_name.as(...)" must > necessarily conflict with a standalone keyword " as ". It seems to me > that it should be possible to unambiguously separate the two without > ambiguity or undue complication of the parser. That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. Reserved words are reserved in all contexts, regardless of whether ambiguity could arise. Otherwise *every* reserved word would have to be allowed right after a '.', and many keywords would have to be allowed as identifiers in other contexts. That way lies PL/1... Furthermore, how would you define the 'as' method? Would you also want to be allowed to write def as(self, target): ... ??? Trust me, it's a slippery slope, and you don't want to start going down there. > So, assuming I now wish to propose a corrective PEP to remedy this > situation for Python 3.1 and beyond, what is the best way to get started > on such a proposal? Don't bother writing a PEP to make 'as' available as an attribute again. It has no chance of being accepted. Instead, think of a different word you could use. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Enthought Python Distribution - New Release
Hey Travis, Congratulations with this release! Are you guys thinking of Python 2.6 yet, now that it's been released? --Guido On Tue, Oct 21, 2008 at 2:53 PM, Travis Vaught <[EMAIL PROTECTED]> wrote: > Greetings, > > Enthought, Inc. is very pleased to announce the newest release of the > Enthought Python Distribution (EPD) Py2.5 v4.0.30002: > > http://www.enthought.com/epd > > This release contains updates to many of EPD's packages, including NumPy, > IPython, matplotlib, VTK, etc. This is also the first release to include a > 3.x version of the Enthought Tool Suite (http://code.enthought.com/). > > The release notes for this release, including the list of included packages, > may be found here: > https://svn.enthought.com/epd/wiki/Python2.5.2/4.0.300/GA > > Many thanks to the EPD team for putting this release together, and to the > community of folks who have provided all of the valuable tools bundled here. > > Best Regards, > > Travis > > > - > About EPD > - > The Enthought Python Distribution (EPD) is a "kitchen-sink-included" > distribution of the Python™ Programming Language, including over 80 > additional tools and libraries. The EPD bundle includes NumPy, SciPy, > IPython, 2D and 3D visualization, database adapters, and a lot of other > tools right out of the box. > > http://www.enthought.com/products/epd.php > > It is currently available as an easy, single-click installer for Windows XP > (x86), Mac OS X (a universal binary for Intel 10.4 and above) and RedHat EL3 > (x86 and amd64). > > EPD is free for 30-day trial use and for use in degree-granting academic > institutions. An annual Subscription and installation support are available > for commercial use (http://www.enthought.com/products/epddownload.php) > including an Enterprise Subscription with support for particular deployment > environments (http://www.enthought.com/products/enterprise.php). > > -- > http://mail.python.org/mailman/listinfo/python-announce-list > > Support the Python Software Foundation: > http://www.python.org/psf/donations.html > -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- http://mail.python.org/mailman/listinfo/python-list
Re: Your feedback on our free Advanced Python tutorial
Hi Aude, Unfortunately I don't have time to review or endorse your Python materials. Good luck, --Guido On Wed, Jul 19, 2017 at 9:44 AM, Aude Barral, CodinGame wrote: > Hi everyone, > > I am co-founder of a startup called CodinGame. > > A few days ago we've launched a project: Tech.io <https://tech.io/>. It's > a > free knowledge-sharing platform that allows tech professionals to learn new > programming concepts through hands-on content crafted by volunteers in the > community. > > Everything runs on our backend. Our system relies on Docker images so we > can play tutorials and demos of virtually any technology from the browser. > > So why this project? Because as more and more resources over the Internet > now need to be paid for (Udacity, Udemy, etc), we want to foster free > online technology education thanks to peer learning. In a sense, we'd like > to become some kind of Wikipedia for tech. > > One of the first tutorials our contributors published is about Advanced > Python Features (hope more will be published soon!): https://tech.io/play > grounds/500/advanced-python-features/advanced-python-features > > I have 2 questions for you: > - Do you think this tutorial could be helpful to your Python user > community? > - Would you be willing to help us spread the word about Tech.io? > > Thanks a lot for checking, > > Cheers! > Aude > > <https://www.codingame.com> > *Aude BARRAL*, Co-Founder > +33 674 632 708 > > [image: https://fr.linkedin.com/in/audebarral] > <https://fr.linkedin.com/in/audebarral> > <https://plus.google.com/u/0/102127747572145483038/posts> > <https://twitter.com/audebarral> <http://www.facebook.com/CodinGame> > <https://www.youtube.com/channel/UCJ6woCHjGCBXqpf91SsAcoQ> > -- > https://mail.python.org/mailman/listinfo/python-announce-list > > Support the Python Software Foundation: > http://www.python.org/psf/donations/ > -- --Guido van Rossum (python.org/~guido) -- https://mail.python.org/mailman/listinfo/python-list
