On Thu, Sep 06, 2007, Neal Becker wrote:
>
> http://www.python.org/dev/peps/pep-0362/
>
> This would be helpful for boost::python. Any thoughts on approving this for
> python-3k?
What would be helpful IMO is using a Subject: line that doesn't require
using a browser to find out what the thread i
I've transferred everything from my spreadsheet to Neal's.
On 9/5/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Neal, Anthony, Thomas W., and I have a spreadsheet that was started to
> keep track of what needs to be done in what needs to be done in 2.6
> for Py3K transitioning:
> http://spreadshee
On 9/6/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > I haven't read it, but it seems very similar to the new annotations
> > > capability in py3k (pep 3107). Will that not suffice?
> >
> > Which I notice has a "Requires: 362
On 9/6/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> > http://www.python.org/dev/peps/pep-0362/
> >
> > This would be helpful for boost::python.
>
> Speaking of helpful...
>
> class X:
> def f(self): pass
>
> class Y(X): pass
>
> ...I would like a mechanism to indicate that Y.f is
> http://www.python.org/dev/peps/pep-0362/
>
> This would be helpful for boost::python.
Speaking of helpful...
class X:
def f(self): pass
class Y(X): pass
...I would like a mechanism to indicate that Y.f is inherited, and I was
hoping that perhaps that information could be
Dnia 04-09-2007, Wt o godzinie 11:09 +0200, Georg Brandl napisał(a):
> Even if it's true that a loop over items is more common than a loop over keys,
> "x in keys" is much more common than "x in items".
In my language iterating over dict yields (key,value) pairs, but the
equivalent of "x in dict"
On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Neal> This would be helpful for boost::python. Any thoughts on
> Neal> approving this for python-3k?
>
> I haven't read it, but it seems very similar to the new annotations
> capability in py3k (pep 3107). Will that not suffice?
On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > I haven't read it, but it seems very similar to the new annotations
> > capability in py3k (pep 3107). Will that not suffice?
>
> Which I notice has a "Requires: 362" field. Perhaps you're good to go. ;-)
I think that is there
On 9/6/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Sep 6, 2007, at 8:33 AM, Neal Becker wrote:
> > http://www.python.org/dev/peps/pep-0362/
> >
> > This would be helpful for boost::python. Any thoughts on approving
> > this for
> > python-3k?
>
> The var_args and var_kw_args definitions are a l
On 06/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> I haven't read it, but it seems very similar to the new annotations
>> capability in py3k (pep 3107). Will that not suffice?
>
> Which I notice has a "Requires: 362" field. Perhaps you're good to go. ;-)
Apparently not (yet,
[Adding Greg P Smith who owns the hashes, and Bill Janssen who has
recently taken over our SSL support.]
Traditionally this is something for which the core developers haven't
had an inclination, so it's been left to 3rd party packages. The
position of the US government on crypto export hasn't help
> I haven't read it, but it seems very similar to the new annotations
> capability in py3k (pep 3107). Will that not suffice?
Which I notice has a "Requires: 362" field. Perhaps you're good to go. ;-)
Skip
___
Python-3000 mailing list
Pytho
Neal> This would be helpful for boost::python. Any thoughts on
Neal> approving this for python-3k?
I haven't read it, but it seems very similar to the new annotations
capability in py3k (pep 3107). Will that not suffice?
Skip
___
Python-3000
On Sep 6, 2007, at 8:33 AM, Neal Becker wrote:
> http://www.python.org/dev/peps/pep-0362/
>
> This would be helpful for boost::python. Any thoughts on approving
> this for
> python-3k?
The var_args and var_kw_args definitions are a little weird. Why use
the empty string instead of None when
http://www.python.org/dev/peps/pep-0362/
This would be helpful for boost::python. Any thoughts on approving this for
python-3k?
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http:/
> This gets at what most interests me -- namely, whether there's a strong
> legal barrier to including more crypto with Python than just the hashes
> we have at the moment. It sounds like the answer is 'yes', but what are
> the details?
The export permission allows for exporting "mass-market" soft
On 9/6/07, Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> (Sorry, it turns out that I posted this reply only to Nick and not to
> the list, so I post it again.)
>
> On 9/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Containment and iteration really do need to be kept consistent and
> > having the
On Sep 6, 2007, at 4:09 AM, Martin v. Löwis wrote:
> There are more issues, of course: some countries restrict the use
> of cryptography. France is given as an example: you need to register
> your cryptography keys with the government (SCSSI) before you can
> use confidentiality-oriented algorithms
On 05/09/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> Rather than resurrecting the old RSA-copyright md5.c I can easily make new
> ones out of the libtomcrypt md5 and sha1 sources the same way i created the
> non-openssl sha256 and sha512 modules.
Which reminds me - when I build Python 3 (on
> On the wider subject of crypto in Python, is there someone who actively
> takes care of this area and who could clarify any legal/export
> restrictions on what gets included with the source distribution?
The PSF does (more specifically, the PSF board, and even more
specifically, Tim Peters). We
On Sep 5, 2007, at 12:09 PM, Martin v. Löwis wrote:
> That's for 2.5. In 3.0 (currently), hashlib requires OpenSSL.
On the wider subject of crypto in Python, is there someone who
actively takes care of this area and who could clarify any legal/
export restrictions on what gets included with the
(Sorry, it turns out that I posted this reply only to Nick and not to
the list, so I post it again.)
On 9/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Containment and iteration really do need to be kept consistent and
> having the value matter when checking for dictionary containment would
> be
22 matches
Mail list logo
