Re: [Python-Dev] Python 2.7 patch levels turning two digit
Not being a Python developer, I normally just lurk on Py-Dev, but I figured I'd throw this out there for this thread: Recent version of Maya embed Python 2.x, and the newer version of Maya (I believe 2012 was the first version) embeds a Python 2.7 compiled with VS 2010. From my experience, most C extensions work across compiler versions, however when they don't, it's generally a fairly difficult to debug issue - at least unless you know what to look for in the call stacks, and have access to the symbol files. Chris On Mon, Jun 23, 2014 at 2:07 PM, M.-A. Lemburg wrote: > On 23.06.2014 22:20, Donald Stufft wrote: > > > > On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote: > > > >> On 23.06.2014 18:09, Donald Stufft wrote: > >>> > >>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis > wrote: > >>> > > > > * Should we make use of the potential breakage with 2.7.10 > > to introduce a new Windows compiler version for Python 2.7 ? > > Assuming it is a good idea to continue producing Windows binaries > for 2.7, I think it would be a bad idea to switch compilers. It will > cause severe breakage of 2.7 installations, much more problematic > than switching to two-digit version numbers. > >>> > >>> I agree with this, we’ve just finally started getting things to the > point where > >>> it makes a lot of sense for binary distributions for Windows. Breaking > all > >>> of them on 2.7 would be very bad. > > > > Err, sorry that “We” was with my pip hat on. > > > >> > >> Not sure what you mean. We've had binary wininst distributions > >> for Windows for more than a decade, and egg and msi distributions > >> for 8 years :-) > > > > Nonetheless, changing the compiler will not only break pip, but every > > automated installer tool (easy_install, buildout) that i’m aware of. The > > blow back for binary installation is going to be huge I think. > > > >> But without access to the VS 2008 compiler that is needed to > >> compile those extensions, it will become increasingly difficult > >> for package authors to provide such binary packages, so we have to > >> ask ourselves: > >> > >> What's worse: breaking old Windows binaries for Python 2.7 > >> or not having updated and new Windows binaries for Python 2.7 > >> at all in a few years ? > > > > At the risk of getting Guido to post his slide again, I still think the > > solution to the old compiler is to just roll a 2.8 with minimal changes. > > It could even be a good place to move to the ssl backport changes > > too since they were the riskier set of changes in PEP466. > > > > But either way, if a compiler does change in a 2.7 release we’ll need > > to update a lot of tooling to cope with that, so any plan to do that > should > > include that and a timeline for adoption of that. > > Sure, and we'd need to hash out possible solutions to minimize > breakage, but first we'll have to see whether we want to consider > this step or not. > > > BTW: It's strange that I'm arguing for breaking things. I'm usually > on the other side of such arguments :-) > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source > >>> Python/Zope Consulting and Support ...http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > > ::: Try our new mxODBC.Connect Python Database Interface for free ! > > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >Registered at Amtsgericht Duesseldorf: HRB 46611 >http://www.egenix.com/company/contact/ > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ckaynor%40zindagigames.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival wrote: > My first reaction to type hints was "yuck", and I'm sure I'm not the only > one to think that. viz (from some pycon slides): > > def zipmap(f: Callable[[int, int], int], xx: List[int], >yy: List[int]) -> List[Tuple[int, int, int]]: My opinion of type hints is: they are great inline, when they are simple. Cases like (I know its not a real-world case, but there are plenty of similarly simple functions): def add(a: int, b: int) -> int: are fine. When you get more complicated examples, especially when they involve complex types (list, tuple, callable, etc). In such cases, it may make sense to predefine a type (I believe the typehints PEP supports some form of typedef - I think just a simple assignment) and use that instead of the full type name. This will generally make the function definition MUCH easier to read. > That sounds like the best of both worlds to me. > - .py files stay beautiful, concise, and easy to read. > - beginners don't have to worry about wading through type definitions when > they find themselves browsing someone else's source > - type information is available to the linters and static file checkers, so > we get all the benefits. > > Sounds great right? Everybody will be happy! So let's nail it down! If I > was in charge, here's what I'd do: > > * standardise the syntax for type hints in 3.5, as per PEP484 > * but: recommend the use of stub files as the preferred place to store hints > * and: deprecate function annotations in the core language > * remove them from the core language altogether in 3.6 The main drawback of using a stub file is that it is much more likely to end up out-of-date, and thus useless at best, than if the types are defined inline. The same issue applies to various alternative proposals such as having the typehints in decorators, but to a lesser degree. The same issue also applies to general comments as well. I would say there are a few major reasons to use stub files: 1) You cannot put the annotations in the source, probably either because the module is a C library, or you must support versions which do not support annotations. 2) You must use annotations for other purposes. 3) The annotations are particularly complicated, and you cannot provide nice names for the various types (likely, because the types are just very difficult to name, such as in the zipmap example, though that one might be easier in a more specific context). Outside of those specific reasons, I would vastly prefer any annotations to be included in the source, where they are much more likely to be updated, rather than in a separate file, where they will likely be forgotten. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] summing integer and class
This list is for development OF Python, not for development in python. For
that reason, I will redirect this to python-list as well. My actual answer
is below.
On Thu, Oct 3, 2013 at 6:45 AM, Igor Vasilyev
wrote:
> Hi.
>
> Example test.py:
>
> class A():
> def __add__(self, var):
> print("I'm in A class")
> return 5
> a = A()
> a+1
> 1+a
> Execution:
> python test.py
> I'm in A class
> Traceback (most recent call last):
> File "../../test.py", line 7, in
> 1+a
> TypeError: unsupported operand type(s) for +: 'int' and 'instance'
>
>
> So adding integer to class works fine, but adding class to integer fails.
> I could not understand why it happens. In objects/abstact.c we have the
> following function:
>
Based on the code you provided, you are only overloading the __add__
operator, which is only called when an "A" is added to something else, not
when something is added to an "A". You can also override the __radd__
method to perform the swapped addition. See
http://docs.python.org/2/reference/datamodel.html#object.__radd__ for the
documentation (it is just below the entry on __add__).
Note that for many simple cases, you could define just a single function,
which then is defined as both the __add__ and __radd__ operator. For
example, you could modify your "A" sample class to look like:
class A():
def __add__(self, var):
print("I'm in A")
return 5
__radd__ = __add__
Which will produce:
>>> a = A()
>>> a + 1
I'm in A
5
>>> 1 + a
I'm in A
5
Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest missing assertNotRaises
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano wrote: > But I can't see this being a useful test. As written, exceptions are still > treated as errors, except for excClass, which is treated as a test failure. I > can't see the use-case for that. assertRaises is useful: > > "IOError is allowed, but any other exception is a bug." > > makes perfect sense. assertNotRaises doesn't seem sensible or useful to me: > > "IOError is a failed test, but any other exception is a bug." > > What's the point? When would you use that? > I've run across a few cases where this is the correct behavior. The most recent one that comes to mind is while testing some code which has specific silencing options: specifically, writing a main file and a backup file, where failure to write the backup is not an error, but failure to write the main is. As such, the test suite should have the following tests: - Failure to write the main should assert that the code raises the failure error. No error is a failure, any other error is an error, that error is a success. (it may also check that the backup was written) - Failure to write the backup should assert that the code does not raise the failure error. No error is a success, that error is a failure, any other error is a error. (it may also check that the main was written) - Both succeeding should assert that the files were actually written, and that no error was raised. Any other result is an error. Now, the difference between a Failure and an Error is more or less a mute point, however I would expect an Error to be any unexpected result, while a Failure is a predicted (either via forethought or prior tests) but incorrect result. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in type dict
On Wed, Mar 7, 2012 at 5:45 PM, Victor Stinner wrote:
> > During the Language Summit 2011 (*), it was discussed that PyPy and
> > Jython don't support non-string key in type dict. An issue was open to
> > emit a warning on such dict, but the patch has not been commited yet.
>
> It's the issue #11455. As written in the issue, there are two ways to
> create such type:
>
> class A(object):
>locals()[42] = "abc"
>
> or
>
> type("A", (object,), {42: "abc"})
>
> Both look like an ugly hack.
>
Here is a cleaner version, using metaclasses (Python 2.6):
class M(type):
def __new__(mcs, name, bases, dict):
dict[42] = 'abc'
return super(M, mcs).__new__(mcs, name, bases, dict)
class A(object):
__metaclass__ = M
>
> Victor
> ___
> 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/ckaynor%40zindagigames.com
>
___
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/archive%40mail-archive.com
