Re: [Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Daniele Tricoli]

On Tuesday, March 15, 2016 11:28:30 AM Marco Beri wrote:
> E chi ti dice che non sia usata in altre lingue? Non stiamo parlando solo
> dell'italiano.

Io sto adottando un altro approccio: imposto il layout per applicazione, 
tenendo la maggior parte[¹] in en_US. E posso passare da un layout all'altro 
al volo, ma non capita quasi mai.

Il compose key forse è carino per gli emoji, ma non volendo ricordare i 
codepoint unicode alla fine mi son scritto una cosa che utilizza un approccio 
differente, ma anche di questi ne uso pochi... quindi non è che sia poi così 
importante.

[¹] ma in genere ho bisogno solo di terminale, editor, browser e MUA, per cui 
tenere la maggior parte con un determinato layout è molto semplice! :)

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

signature.asc
Description: This is a digitally signed message part.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] attributi astratti?

[enrico franchi]

2016-03-15 17:15 GMT+00:00 Marco Santamaria :


> In realtà da Python 3.3 è deprecato in favore dell'uso combinato di
> @property e @abstractmethod.
>

Vero. Comunque il concetto e' quello.


> Il guaio di questo approccio è che le classi derivate devono implementare
> un metodo decorato con @property e non basta definire una proprietà
> (giustamente non attributo, che è più generale) come con @abstractmethod
>

Esatto. Solo che non e' banale fare veramente un "abstractattribute".



> Poi mi è venuta in mente anche una quarta possibilità: chiamare hasattr
> nel metodo __new__ della classe astratta, cosa che segnala l'eccezione un
> po' prima che se chiamato in __init__
>

Farlo in __new__ e' marginalmente meglio che farlo in __init__ per vari
motivi (non tanto il fatto che sia segnalata "un po' prima" -- dal punto di
vista dell'utente l'eccezione "esce" nello stesso punto). E non e'
esattamente chiaro se sia meglio controllare con hasattr (o equivalente)
sull'oggetto oppure guardare i parametri di input.

Quello che vorrei fosse chiaro e' che in questo universo il tuo problema e'
che dipendi in modo marcato da cose fuori dal tuo controllo. Cioe', il
motivo per cui ti stai sbattendo per questo "abstract attribute" e' che
vuoi di fatto dare sta libreria in mano a terze parti (potenzialmente anche
interni) e vuoi evitare che il contratto del tuo codice non sia mantenuto
(e se non lo e', segnalarlo in modo opportuno).

Solo che Python ti consente di fare tantissime cose (anche molto sensate) e
che il *come* le fai puo' vuole dire che il tuo controllo funziona o
meglio. Per dire... cosa succede se uno ha delle namedtuples nella
gerarchia da qualche parte? Mica banale...



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-15 19:09 GMT+01:00 enrico franchi :

> Ottimo. Mi fa piacere che per te funzioni. Vorrei solo che sia chiaro che
> non e' un caso generale che sia facilmente estensibile ad altri business in
> modo automatico. Appena cambi un pochetto le regole del business e' facile
> che non funzioni piu' tanto bene.
>

Questione di scala Enrico. Che poi sia giustissimo e sacrosanto scrivere i
test e' altro discorso. Ma per le cose che fa Giovanni i bug nascosti tra
le pieghe del codice magari sono meno nascosti.
Se hai una applicazione con tre bottoni, ciascuno fa una cosa specifica e
solo una, indipendentemente dall'ordine in cui li stai premendo, i bug sono
facile da beccare con il solo test funzionale di premere tutti e tre e
vedere che ciascuno faccia solo quello che deve fare. Se sempre stesso caso
ma a seconda dell'odine di pressione accade qualcosa di differente (premi
tutti e tre in un dato ordine succede una cosa, li premi in un altro
cuccede un'altar cosa) gia' piu' difficile beccare il bug con il test
funzionale. Se poi i bottonoi sono 30 o 300 ...

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 14:21 GMT+00:00 Giovanni Porcari :

>
> Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.
>
> Però come dicevo in un'altra mail è un problema di risorse che puoi avere
> e non avere
> e le compatibilità economiche non sono meno importanti di quelle tecniche.
>

Si, appunto. Per determinati business (che so, se fai servizi web based) il
costo di un baco in produzione sufficientemente grave puo' anche nella
peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia
nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel
lungo termine). Se il business fa billing sulla base delle transazioni dei
clienti, downtime vuole dire potenzialmente milioni di dollari di mancate
entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se
non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto
questo coinvolge ancora una volta mancate entrate)

Certo, se vendi software "boxed" sei in un mondo completamente diverso.
Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti
va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti
preoccupare. In altri casi questo e' un pochetto piu' complicato.

Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più
> di 40 anni
> e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.
>

Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e'
tutta diversa.

Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare
molto di questo tipo di affermazioni.

Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno.
Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di
scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in
piedi la baracca (che a sua volta e' completamente trascurabile rispetto al
costo di fallire davvero).

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o
> attenzione non lo so.
>

La fortuna non perdura in eterno, il senso di responsabilita' non aiuta
(ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un
problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche
dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma
soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in
cui sei disattento.

Se vai a vedere come gestiscono le cose quelli che *non* possono
permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con
l'omino dei lavori in corso sul monitor del 747 che sta precipitando con
500 persone a bordo -- sorry, we are working for you: ATC will be online in
a couple of hours, please consult your onboard spiritual advisor for your
last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di
responsabilita'". Semmai hanno svariati team di QA che fanno test manuali,
automatici, randomizzati e pagano licenze piuttosto costose per tool che
fanno analisi statica e dimostrano l'assenza di determinati bachi in
determinate parti del codice. E a volte tutto questo si rompe e nonostante
tutto si va Arianne 5.

Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di
sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E
quindi via di compromessi. Oltretutto un moderno sistema software e'
*molto* piu' complicato della maggior parte dei sistemi mission critical di
quel tipo (principalmente perche' il costo di non introdurre una feature
puo' essere molto piu' alto del costo del rischio di un downtime).

Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
>

"True man do not write bugs". No. La gente scrive i test quando lavora
bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il
culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale
ragione per non scriverli? Risparmio tempo? In generale si dimostra che non
e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno
se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok...
ma non e' un gran piano nel caso generale.

Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>

Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo
invisibile con illuminazione a lume di candela fatta dal pubblico
sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E
un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una
motosega al posto della zampa destra.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è
> una cosa meravigliosa.
> Dico solo che io, purtroppo, non me la posso permettere :)
>

E io non conosco il tuo business, per cui non posso e non voglio commentare
oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare
di nuovi? Allora vuole dire che stai facendo 

Re: [Python] attributi astratti?

[Marco Santamaria]

Il giorno 15 marzo 2016 17:38, enrico franchi  ha
scritto
>
> O a me non e' chiaro quale sia il tuo problema concreto, oppure tu non hai
> guardato la doc per abstractproperty.
>
> https://docs.python.org/2/library/abc.html#abc.abstractproperty
>

In effetti lo avevo visto, e mi era sembrato un po' più appropriato che
richiedere un metodo come con @abstractmethod. In realtà da Python 3.3 è
deprecato in favore dell'uso combinato di @property e @abstractmethod. Il
guaio di questo approccio è che le classi derivate devono implementare un
metodo decorato con @property e non basta definire una proprietà
(giustamente non attributo, che è più generale) come con @abstractmethod:

In [1]: from abc import ABC, abstractmethod
>
> In [2]: class B(ABC):
>...: @property
>...: @abstractmethod
>...: def foo(self): pass
>...:
>
> In [3]: class A(B):
>...: foo = 'bar'
>...:
>
> In [4]: A()
> Out[4]: <__main__.A at 0x7f2940d14160>
>
> In [5]: A().bar
> ---
> AttributeErrorTraceback (most recent call last)
>  in ()
> > 1 A().bar
>
> AttributeError: 'A' object has no attribute 'bar'
>
> In [6]: class C(ABC):
>...: @abstractmethod
>...: def foo(self): pass
>...:
>
> In [7]: class D(C):
>...: foo = 'bar'
>...:
>
> In [8]: D()
> Out[8]: <__main__.D at 0x7f2940d320f0>
>
> In [9]: D.foo
> Out[9]: 'bar'
>

Comunque abstractproperty (o equivalentemente property + abstractmethod) si
avvicina di più a quello che cercavo.

Poi mi è venuta in mente anche una quarta possibilità: chiamare hasattr nel
metodo __new__ della classe astratta, cosa che segnala l'eccezione un po'
prima che se chiamato in __init__

Grazie,
Marco

-- 
|_|0|_|
|_|_|0|
|0|0|0|
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] attributi astratti?

[enrico franchi]

2016-03-11 16:13 GMT+00:00 Marco Santamaria :

sto lavorando ad un piccolo framework nel quale mi sento autorizzato ad
> usare il modulo abc per creare delle classi astratte/interfacce per
> permetterne l'estensione.
>

Ok. Va bene.


>
> Mi sono trovato spesso a dover assicurare la presenza di un attributo
> nelle classi derivate da una classe astratta, senza avere la possibilità di
> fornire un valore di default ragionevole.
>

O a me non e' chiaro quale sia il tuo problema concreto, oppure tu non hai
guardato la doc per abstractproperty.

https://docs.python.org/2/library/abc.html#abc.abstractproperty

E' una cosa sottilmente diversa da quello che vuoi fare tu... che vuole
dire che potrebbe essere perfetto (o essere perfetto una volta che ti
orienti nella sua direzione) oppure totalmente inadatto. Questo lo puoi
sapere solo tu.

Personalmente lo considererei perche' si muove nello stesso spazio di
problemi che descrivi. Ovviamente non funziona *esattamente* come quello
che descrivi. In pratica lui ti assicura la presenza di una *property* che
fa quello che vuoi, mentre un attributo e' un concetto un pochetto piu'
generale.

In [1]: import abc

In [2]: class B(object):
   ...: __metaclass__ = abc.ABCMeta
   ...: @abc.abstractproperty
   ...: def foo(self): pass
   ...:

In [3]: class A(B): pass

In [4]: A()
---
TypeError Traceback (most recent call last)
 in ()
> 1 A()

TypeError: Can't instantiate abstract class A with abstract methods foo

In [5]: A(foo='bar')
---
TypeError Traceback (most recent call last)
 in ()
> 1 A(foo='bar')

TypeError: object() takes no parameters

In [6]: class AOK(B):
   ...: @property
   ...: def foo(self): return 42
   ...:

In [7]: AOK().foo
Out[7]: 42

In [8]: class ABad(B):
   ...: def __init__(self, foo):
   ...: self.foo = foo
   ...:

In [9]: ABad(foo=42).foo
---
TypeError Traceback (most recent call last)
 in ()
> 1 ABad(foo=42).foo

TypeError: Can't instantiate abstract class ABad with abstract methods foo


> Data la natura dinamica di Python questo può essere fatto in vari modi, ma
> mi chiedo quale sia quello più 'idiomatico' in Python 3.4, facendo in modo
> che venga sollevata il prima possibile un'eccezione chiara se
> quell'attributo non viene definito.
>
> Al momento mi sono venute in mente tre soluzioni:
>
>1. controllare con hasattr la presenza dell'attributo nel metodo
>__init__ della classe astratta
>2. definire nella classe astratta una proprietà (decorata con
>@property) che solleva un'eccezione NotImplementedError
>3. definire nella classe astratta un metodo astratto (decorato con
>@abstractmethod) con lo stesso nome dell'attributo
>
> Sto usando la 3. quando possibile perché solleva un'eccezione prima delle
> altre, ma non mi piace molto l'idea di richiedere un metodo quando voglio
> un attributo.
>

Ok. Se stai usando la 3, passare ad abstractproperty ti avvicina un po' a
quello che vuoi. La 2 e' una versione fatta con lo scotch di
abstractproperty (o meglio, sta ad abstractproperty come fare un metodo che
ti tira not implemented sta ad abstractmethod: specificamente la differenza
e' quando ottieni l'errore; abstract* ti da un errore se quando istanzi
l'oggetto un determinato ente non e' nell'mro dell'oggetto, viceversa
tirare sulla chiamata te lo segnala appunto se e solo se lo chiami... non
entro nel merito del quando preferisco uno o l'altro perche' e' complicato).

hasattr funzionicchia, ma hai un sacco di edge case fastidiosi. Per esempio
ti rende molto vulnerabile all'ordine di risoluzione dei metodi (mro) e al
fatto che qualche derivata *non* chiami l'__init__ che vorresti tu. Secondo
me e'facile impiccarsi con una soluzione che apparentemente funziona, ma in
pratica lascia fuori sufficienti casi da scoprire in produzione che
effettivamente non funzionava.

abstractproperty ha il vantaggio che a fronte di essere marginalmente piu'
scomodo da scrivere e' molto chiaro nell'intento ed e' relativamente
improbabile scavalcarlo "per errore".



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Offerta di lavoro 20Tab

[Roberto De Ioris]

Ciao a tutti, 20Tab, con sede a Roma (zona est) e’ alla ricerca di un
programmatore Python full time on-site.
La base dell’offerta e’ contratto a tempo indeterminato
con netto tra i 1200 e i 1500 in base alle competenze del candidato.

La maggior parte dei progetti riguarda applicazioni web realizzate con
Django, quindi la conoscenza del framework e’ ampiamente gradita (ma non
necessaria).

Skill apprezzate sono la conoscenza di PostgreSQL, redis, Solr, uWSGI,
nginx, Jira/Taiga e dimestichezza con gli ambienti Linux e/o Mac.

Requisiti necessari sono il sapere utilizzare git e dare una adeguata
copertura di test al codice.

L’offerta e’ aperta a candidati di tutti i sessi, religioni, etnie e gusti
alimentari.

Se interessati potete inviare il vostro curriculum a i...@20tab.com

Grazie e scusate il disturbo

-- 
Roberto De Ioris
http://unbit.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Marco Beri]

2016-03-15 11:15 GMT+01:00 Nicola Larosa :

> Vero, ma solo per la "e". Per le altre vocali non vedo perché poter
> sbagliare, visto che l'alternativa è sempre sbagliata.
>

E chi ti dice che non sia usata in altre lingue? Non stiamo parlando solo
dell'italiano.

ę ḝ Ḝ

:-)


> Cerca sul tuo pc qui /usr/share/X11/locale/en_US.UTF-8/Compose
>
> Ottimo, grazie. Curiose le tante linee vuote all'inizio, dev'essere un
> file generato coi template di Django. ;-)
>

:D :D

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Nicola Larosa]

> Nicola Larosa wrote:
>> - facile produrre per errore lettere non esistenti nella lingua
>> italiana (solo la "e" ha entrambi gli accenti acuto e grave, le
>> altre vocali hanno solo quello grave);

Marco Beri wrote:
> Beh, devi sapere quali accenti usare. Perché e non perchè :-)
> 
> Non sbagli più una volta che sai che solo con la "e" devi usare
> l'apice normale.

Vero, ma solo per la "e". Per le altre vocali non vedo perché poter
sbagliare, visto che l'alternativa è sempre sbagliata.


>> - il pannello di configurazione di Ubuntu consente solo poche scelte
>>   per la Compose Key, tutte scomode; ho provato a guardare in
>>   unity-tweak-tool e gnome-tweak-tool, ma non la trovo.

> Come tutte scomode? Il caps lock è la morte sua. Per cosa lo usi?

Spiacente, settato come Ctrl da decenni (pur non usando Emacs :-P ). Il
tasto Left Ctrl è scomodo per la maggior parte delle operazioni, e ora
l'ho settato a Compose. Però lo usavo come Ctrl per pochi casi, mi
tocca un po' di retraining.

Tutto perché i polli interfaccisti ex-colleghi restringono senza motivo
le possibilità degli utenti. Almeno includete l'arruginito
Pause/Break, che sta lì a far nulla. :-P


> Mica vorrai una tastiera stateful? :-D

Non è il caso di insultare adesso. ;-)


>> Dove trovo una lista dei caratteri generabili?

> Sono tanterrimi.
> 
> Cerca sul tuo pc qui /usr/share/X11/locale/en_US.UTF-8/Compose

Ottimo, grazie. Curiose le tante linee vuote all'inizio, dev'essere un
file generato coi template di Django. ;-)

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Marco Beri]

2016-03-15 10:33 GMT+01:00 Nicola Larosa :

> >> Massimiliano Modena wrote:
> >>> OT nell' OT: con la tastiera layout en_US come faccio le lettere
> >>> accentate?
>
> > Nicola Larosa wrote:
> >> Se hai Ubuntu usa la tastiera:
> >>
> >> "Italian (US keyboard with Italian letters)"
>
> Marco Beri wrote:
> > Tutta la vita compose key.
> >
> >  CCCP -> ☭
> >  <3 -> ♥
> >  c, -> ç
> >  C= -> €
> >  E' -> É
> >  E` -> È
> >  (10) -> ⑩
>
> Mi sarà utile per Duolingo, grazie. Molto versatile, ma con dei difetti:
>
> - facile produrre per errore lettere non esistenti nella lingua italiana
>   (solo la "e" ha entrambi gli accenti acuto e grave, le altre vocali
>   hanno solo quello grave);
>

Beh, devi sapere quali accenti usare. Perché e non perchè :-)

Non sbagli più una volta che sai che solo con la "e" devi usare l'apice
normale.

- è una feature storica di Linux, e documentazione e configurazione sono
>   sparse in giro e incasinate;
>
> - il pannello di configurazione di Ubuntu consente solo poche scelte
>   per la Compose Key, tutte scomode; ho provato a guardare in
>   unity-tweak-tool e gnome-tweak-tool, ma non la trovo.
>

Come tutte scomode? Il caps lock è la morte sua. Per cosa lo usi? Mica
vorrai una tastiera stateful? :-D

Il layout di tastiera che indico sopra è un'ottima scelta per generare
> in modo semplice e privo di errori le accentate della lingua italiana
> che si usano nella grande maggioranza dei casi (maiuscole comprese). La
> Compose Key può essere un'utile aggiunta per caratteri meno frequenti.
> Dove trovo una lista dei caratteri generabili?
>

Sono tanterrimi.

Cerca sul tuo pc qui /usr/share/X11/locale/en_US.UTF-8/Compose

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Alessandro Dentella]

On Tue, Mar 15, 2016 at 10:33:54AM +0100, Nicola Larosa wrote:
> >> Massimiliano Modena wrote:
> >>> OT nell' OT: con la tastiera layout en_US come faccio le lettere
> >>> accentate?
>
> > Nicola Larosa wrote:
> >> Se hai Ubuntu usa la tastiera:
> >>
> >> "Italian (US keyboard with Italian letters)"
>
> Marco Beri wrote:
> > Tutta la vita compose key.

concordo

> >
> >  CCCP -> ☭

> >  <3 -> ♥
> >  c, -> ç
> >  C= -> €
> >  E' -> É
> >  E` -> È
> >  (10) -> ⑩
>
> Mi sarà utile per Duolingo, grazie. Molto versatile, ma con dei difetti:
>
> - facile produrre per errore lettere non esistenti nella lingua italiana
>   (solo la "e" ha entrambi gli accenti acuto e grave, le altre vocali
>   hanno solo quello grave);

nella tastiera ci sono molti altri tasti che se schiacciati a muzzo
danno parole inesistenti... ;-*

capita poi di scrivere in altre lingue, non cambio layout apposta per
scrivere in tedesco o in francese.

Poi emacs mi fa l'autocomposizione che è ancora più comoda lettera-accento
diventano lettera accentata se sei in text-mode...

sandro
*:-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT] Mail di Enrico Bianchi in spam

[Nicola Larosa]

> Nicola Larosa wrote:
>> Se hai Ubuntu usa la tastiera:
>>
>> "Italian (US keyboard with Italian letters)"

Alessandro Re wrote:
> Non solo su Ubuntu per fortuna :) c'è anche su Fedora e molte altre
> distro per quanto ne so.

Giusto.


> AltGr + a per à oppure il tasto sotto per l'altro accento
> AltGr + z per á
> 
> Funziona con tutte le vocali e hai anche le maiuscole accentate :)

Uhm. Questi accenti sbagliati (in italiano, ma la tastiera è italiana)
non c'erano fino a qualche tempo fa. Non mi sembra una buona idea averli
aggiunti, troppo facile sbagliare così.

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Lettere accentate con tastiera en_US (era: Re: [OT] Mail di Enrico Bianchi in spam)

[Nicola Larosa]

>> Massimiliano Modena wrote:
>>> OT nell' OT: con la tastiera layout en_US come faccio le lettere
>>> accentate?

> Nicola Larosa wrote:
>> Se hai Ubuntu usa la tastiera:
>>
>> "Italian (US keyboard with Italian letters)"

Marco Beri wrote:
> Tutta la vita compose key.
> 
>  CCCP -> ☭
>  <3 -> ♥
>  c, -> ç
>  C= -> €
>  E' -> É
>  E` -> È
>  (10) -> ⑩

Mi sarà utile per Duolingo, grazie. Molto versatile, ma con dei difetti:

- facile produrre per errore lettere non esistenti nella lingua italiana
  (solo la "e" ha entrambi gli accenti acuto e grave, le altre vocali
  hanno solo quello grave);

- è una feature storica di Linux, e documentazione e configurazione sono
  sparse in giro e incasinate;

- il pannello di configurazione di Ubuntu consente solo poche scelte
  per la Compose Key, tutte scomode; ho provato a guardare in
  unity-tweak-tool e gnome-tweak-tool, ma non la trovo.

Il layout di tastiera che indico sopra è un'ottima scelta per generare
in modo semplice e privo di errori le accentate della lingua italiana
che si usano nella grande maggioranza dei casi (maiuscole comprese). La
Compose Key può essere un'utile aggiunta per caratteri meno frequenti.

Dove trovo una lista dei caratteri generabili?

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT] Mail di Enrico Bianchi in spam

[Alessandro Re]

On Mar 14, 2016 7:41 PM, "Nicola Larosa"  wrote:
>
> Massimiliano Modena wrote:
> > OT nell' OT: con la tastiera layout en_US come faccio le lettere
> > accentate?
>
> Se hai Ubuntu usa la tastiera:
>
> "Italian (US keyboard with Italian letters)"

Non solo su Ubuntu per fortuna :) c'è anche su Fedora e molte altre distro
per quanto ne so.

AltGr + a per à oppure il tasto sotto per l'altro accento
AltGr + z per á

Funziona con tutte le vocali e hai anche le maiuscole accentate :)
Ciauz
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT] Mail di Enrico Bianchi in spam

[Massimiliano Modena]

On Mon, Mar 14, 2016 at 8:41 PM, Nicola Larosa > wrote:


Massimiliano Modena wrote:
> OT nell' OT: con la tastiera layout en_US come faccio le lettere
> accentate?

Se hai Ubuntu usa la tastiera:

"Italian (US keyboard with Italian letters)"


Tutta la vita compose key.

 CCCP -> ☭
 <3 -> ♥
 c, -> ç
 C= -> €
 E' -> É
 E` -> È
 (10) -> ⑩

Una figata unica. Mai più senza.

Ciao.
Marco.

Purtroppo, windows 7. Pero' me lo segno!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python